CSL Notebook Topic
To  CSL  Date February 10, 1984
From Mark Brown  Location PARC
Subject Alpine status  Organization CSL
Came from /Indigo/Alpine/Doc/AlpineStatus.tioga
Last edited by MBrown on February 10, 1984 1:09:30 pm PST
Abstract This memo describes the existing documentation for Alpine, and tells where to find it. Based on information from Luther's logbook, it gives the history of operating a public Alpine server. Finally, it describes the known problems with Alpine software, and makes suggestions about possible future development.
1. Alpine documentation
All documentation for Alpine is stored on /Indigo/Alpine/Doc/. This directory has six subdirectories, as follows:
Admin/ — how to administer an Alpine server. Tells how to create a server from scratch, how to create accounts, how to restart after crashes, and so forth.
Client/ — how to write programs that call an Alpine server.
Design/ — the internal design of the Alpine server, including how to build Alpine from its Cedar source code.
EarlyDesign/ — memos from early in the Alpine project.
Mail/ — mail exchanges on the subject of Alpine.
Talks/ — notes and slides for talks on Alpine.
User/ — how to be a user of an Alpine server.
Obviously, the most recently written documentation is the most likely to reflect the current truth.
2. Experience with Luther
Luther, the public Alpine server, has been in service since March 1983. The Alpine server code running on Luther has not been changed in a significant way since June 27 1983, not long after the load of Walnut users began to build up. In August and September 1983 Luther went through a period of unreliability due to Dorado hardware problems. In October 1983 Luther had "DiskLabelCheck" problems caused by a Dorado microcode bug. In January 1984 a software problem, known as "ServerBusy" , came to the fore and we worked around it by restarting Luther occassionally. Also in January 1984 the new Cedar file stream package found a two bugs in the Alpine server code. The "FileInUse" bug was not easy to fix in Cedar 4.4 but would disappear in Cedar 5.0, so we did nothing about it. The "LogMap" was fixed a couple of days after it apperared. In February 1984 the Alpine server code was converted from Cedar 4.4 to Cedar 5.1, and this was installed on Luther on February 9, 1984.
Summary of Luther restarts since July 1, 1983:
Hardware problem, 23
ServerBusy bug, 13
FileInUse bug, 7
LogMap bug, 5
Install software, 5
DiskLabelCheck (Dorado microcode) bug, 4
Other Alpine bugs, 3
There have been about two restarts per week, on the average, and two cold starts.
3. Known software problems
1. The following are known software problems that can cause crashes:
The server does not place any a priori limit on concurrency. This means it is possible to run out of processes or frame space or even virtual memory. To reduce the probability of running out of an important resource we limit the total number of concurrent transactions on an Alpine server. This does not fix the basic problem, but does make it less likely to occur. The Cedar 5 release relaxed the most serious limit (local frame space.)
The code that kills off inactive transactions is not quite right. As a result, the server can fill up with inactive transactions. When this happens, a request to create a new transaction returns a "server busy" indication.
The code for warm start (crash recovery) is not quite right. If the server crashes because the online log is about to fill up, restart sometimes fails. Under normal conditions, the system will abort transactions to keep the online log from filling up, but sometimes it does not work. This forces a cold start.
2. The following are known problems that can cause unnecessary transaction aborts:
When a transaction is commit-and-continued (e.g. Walnut "Commit" button), it does not release any locks. This is a problem because the transaction may hold a lock on the owner database file, acquired in order to adjust the "space in use" after a file was extended. If some other transaction then needs to create or extend a file, it will either be blocked, or will abort the transaction holding the lock. Lock conflicts on the owner database cause most Walnut aborts.
When one transaction performs a lot of udpates, it may cause other transactions to abort, even if they are only performing reads.
3. The following are shortfalls that are not crippling to current clients, but limit Alpine's future use:
The system is limited to a single logical disk volume. There is no volume-location service, only the server-location service provided by RPC.
There is no way to change the size of the online log from its initial size.
There is no scavenger, either for Cedar files or for Alpine, a client of the Cedar files.
There is no incremental backup, and no backup at all that does not rely on IFS. Two-copy logging is not implemented.
All Alpine servers have the same password. Anyone who knows the password can masquerade as an Alpine server, say as Luther, by simply exporting the Alpine interfaces.
4. The future
Alpine provides a useful service in its present condition. As long as Cedar does not change much, and the pattern of Alpine use does not change much, Alpine should continue to provide service, and will only require occasional restarts.
The time to repair a Dorado processor is unpredictable and not easily bounded. A complete board-swap may not fix what ails a Dorado. The only way to guarantee daily availability of a Dorado server is to provide a "hot spare". One possibility is to cable two machines in the same rack, attach both machines to the same T-300s, and switch from one to the other in case of a difficult to fix hardware problem. The hot spare can be used as a pool machine, subject to emergency preemption.
It seems ill-advised for anyone to make a change to Alpine software that is not strictly necessary unless that person has made a commitment to the continuing development and support of Alpine. There just aren't any "simple" changes that are also useful.
Anyone who understands Alpine and its clients and is committed to Alpine's continuing development will also be in a good position to decide what needs to be done. I would be happy to provide the informal consulting to get such an effort started.