xerox IFS Status and Plans Nov77 free download

File name IFS_Status_and_Plans_Nov77.pdf

Inter-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