File name IFS_Status_and_Plans_Nov77.pdfInter-Office Memorandum
To IFS Project Date November 10, 1977
From Ed Taft and David Boggs Location Palo Alto
Subject IFS Status and Plans Organization PARC/CSL
)(EROX
Filed on: StatusAndPlans.bravo
IFS is now at a stage in which it is available as a limited service, with limited capabilities
and reasonably good reliability. It is now time to pause and consider how much additional
effort should be invested in the project, and in what areas.
We recently conducted a review of the project, and our tentative decisions are presented here
also. Members of the review committee were Chuck Geschke, Butler Lampson, Severo
Ornstein, and Mike Schroeder.
Present Status
As a file server, IFS now supports most of the facilities available on Maxc. Exceptions
include file protections, direct shipment of files for printing, and various odds and ends.
With completion of the Backup system and Scavenger, file storage is now quite reliable.
The most serious shortcoming of the present system is its performance. We presently permit
only five simultaneous users, and even with that load the system's performance is often very
poor. Until recently the system crashed occasionally due to deadlocks arising from running
out of memory.
We have not yet made a detailed analysis of the performance bottlenecks, but we have a good
idea of where the problems lie. Unfortunately, they are not amenable to straightforward
sol ution.
The Alto's main memory is divided into three regions: resident code, resident storage, and
paging buffers for the software virtual memory. At present there are 32 1024-word paging
buffers, which are used for a variety of purposes: code overlays (of which there were 61 at .
last count), server stacks (one per FTP or Chat user), stream buffers (one per file actively
being transferred), B-Tree pages, large blocks allocated temporarily for scratch use, and
several others.
The manner in which the Bcpl stack and overlay mechanisms work exacerbates the main
memory shortage. Server stacks are allocated contiguously and can grow quite large (nearly
1024 words each). Once created, they cannot be moved or swapped out until the server is
destroyed. Similarly, a code overlay cannot be moved or swapped out if any of its
procedures is pending on any process's stack. Obviously, if there are several processes doing
. different things, many overlays will be locked in memory and few paging buffers will be left
. for other purposes.
2
We have recently expended about two man-weeks of effo |
