Schauble.Multics@MIT-MULTICS@sri-unix (07/20/82)
Date: 25 June 1982 00:06 edt The Unix V6 file system had a rather severe limitation on the size of a single filesystem. I understand that this is becuase the block numbers in the inodes were stored as single words. V7 removes this restriction. Yet, I am told that it is standard practice on V7 systems to continue to partition mass storage devices. Is there some non-obvious advantage to be gained from this?
sdyer@BBN-UNIX@sri-unix (08/08/82)
From: Steve Dyer <sdyer@BBN-UNIX> Date: 20 Jul 1982 10:43:08 EDT (Tuesday) I have several theories regarding the continuing partitioning of V7 file- systems, none of which I am willing to defend strongly: First, that habits die hard. Many users upgraded from V6, and continued to keep the status quo. Second, keeping many file systems on a single pack prevents file-system damage from spreading out across the entire surface, limiting the damage to only one file system. Third, and I haven't checked this with any measurements, one might conjecture that multiple file-systems on a pack would help optimize head motion, since the i-list and data blocks would be less spread- out across the disk. This, provided that only one of the file-systems would be heavily used at one time.
dan2@BBN-UNIX@sri-unix (08/08/82)
From: Dan Franklin <dan2@BBN-UNIX> Date: 20 Jul 1982 12:52:39 EDT (Tuesday) The reasons I know for continuing to divide disks into partitions (usually two: a small one for the root, and /usr) are: 1. Efficiency. With inodes located at one end of the file system, resolving a pathname requires repeatedly moving the head from one end of the file system to the other as first an inode, then a series of directory blocks, then another inode, etc. are read in. Having several smaller filesystems minimizes the total head movement and hence the time it takes. (This reason goes away with the 4.2BSD filesystem organization.) 2. Protection. Should something horrible happen to part of the disk, it would be nice if it only incapacitated the root (which is small and can be brought back quickly; also doesn't change as often as /usr, so going to the morning's dump is unlikely to bother anyone) or if it only broke /usr (which lets you use all the programs on the root to find and fix the problems with /usr). "Something horrible" can also include running out of space; it's nice when running out of space on /usr doesn't stop system programs using the root (or using pipes) from working.
howard@Parc-Maxc@sri-unix (08/20/82)
Date: 9-Aug-82 8:30:31 PDT (Monday) How Ken Thompson (at least used to) run his system might help explain things. Ken had two RP06, with each disk having identical sized root, swap and user file systems. He would run with Root and Swap on HP00, and the user file systems on HP1x; th