Heading:

Pilot development that would benefit Alpine

Page Numbers: Yes X: 527 Y: 10.5"

Inter-Office Memorandum

ToRoy Levin, Dale KnutsenDateMay 3, 1981

FromMark BrownLocationPalo Alto

SubjectPilot development that wouldOrganizationCSL

benefit Alpine

XEROX

Filed on: <Alpine>Doc>PilotDevelopmentForAlpine.memo

General

Alpine requires robustness, large capacity, and speed from the Pilot file facilities.

The desirability ratings below range from 1 (very important) to 4 (maybe not worth any effort.)

Disk error handling

[1] Soft read error logging. A soft read error (recovered by re-reading) should be an event that can be logged. A high frequency of soft read errors on a page may indicate that the page should not be used (is this true?)

[2] Using ECC to recover from read errors. Pilot currently recovers from read errors by re-reading (with occasional recalibration.) When this fails, the disk’s ECC should be used to correct the problem if possible. (The ECC is a last resort because it has a non-negligible probability of "correcting" an error incorrectly.)

[1] Graceful handling of hard read errors. A hard read error can only be corrected by high-level recovery procedures. These procedures should not have to scan the enitre file system to find the bad page.

Disk channel

[2] Scheduling of disk commands. When multiple drives are attached, does the system perform overlapped seeks if possible? Is an "elevator algorithm" needed for scheduling commands to a single drive (this was removed in Rubicon)?

Performance tools

[1] Spy. This includes work to better account for I/O time, both for client programs and for Pilot internal I/Os (e.g. reading VFM pages.)

[3] Performance monitoring of Pilot internal data structures. This means file cache, etc.

Volumes

[1] Allow a logical volume to span multiple physical volumes.

[1] Allow a logical volume’s size to be changed. Perhaps this is an offline operation.

[2] Performance with multiple volumes open. Pilot keeps only one logical volume root page open at a time. A server will reference many logical volumes.

[4] Perform in situ reorganization of a volume for better file contiguity. Perhaps this is an offline operation; it is difficult in any case, unless it is offline and fully backed up.

Files

[3] Improve page allocation strategy. Improvement is for better contiguity.

[3] Improve implementation of volume file map. Improvement is for better contiguity, better caching of VFM pages from multiple volumes.

Swapping

[2] Improved communication with swapper. Clients of Alpine will not see a mapped-file interface like Pilot’s. They will see either read/write or a "buffer manager". For the buffer manager to perform well, it needs some help from the swapper. In particular, when the swapper decides to swap out a page controlled by the buffer manager, the buffer manager should get a chance to dispose of it first. There are two cases: the page may be "clean" from the buffer manager’s point of view, hence not worth writing out, or it may be "dirty" from the buffer manager’s point of view, but the buffer manager may wish to write it somewhere other than the anonymous backing file.