gnu@hoptoad.uucp (John Gilmore) (10/03/86)
In article <15583@mordor.ARPA>, jdb@mordor.ARPA (John Bruner) writes: > Sun's partition table on the disc is very convenient. Unfortunately, > their placement of it is not. They put the disc label in the first > sector on the volume. This is OK if your machine's ROM knows about it, > but if the hardware bootstrap wants to read block 0 (as the VAX does) > it is a little inconvenient. :-) This should be solvable by putting the partition table in the END of block 0. Presumably a short piece of code at the FRONT of block 0 can read in a few other blocks and jump to them. Note that during bootstrap, you may not know how to find block N (N > 1) since you won't know how many heads, sectors/track, etc exist. That information is also in the Sun partition table. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
henry@utzoo.UUCP (Henry Spencer) (10/06/86)
I too thought it would be a good idea to have the partition table on
the disk it partitioned, until I read a paper on the Cray-2 Unix port.
They had the right idea: the size and disk location of each partition
is recorded in the /dev inode for it. The kernel stashes the details
in internal tables when such an inode is opened or mounted. It seems
to me that this is a cleaner solution all around.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henryshannon@sun.uucp (Bill Shannon) (10/09/86)
> I too thought it would be a good idea to have the partition table on > the disk it partitioned, until I read a paper on the Cray-2 Unix port. > They had the right idea: the size and disk location of each partition > is recorded in the /dev inode for it. The kernel stashes the details > in internal tables when such an inode is opened or mounted. It seems > to me that this is a cleaner solution all around. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry Unless I misunderstand, this seems wrong. The partitioning of a disk is not related to some entries in some /dev directory somewhere, but is related to the data on the disk. The disk itself should contain the partitioning information. When the disk moves to another machine, the partition information should move with it. Also, where do you find the partition information for the disk on which the filesystem containing /dev resides? Bill Shannon
chris@umcp-cs.UUCP (Chris Torek) (10/09/86)
In article <7195@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >I too thought it would be a good idea to have the partition table >on the disk it partitioned, until I read a paper on the Cray-2 Unix >port. ... the size and disk location of each partition is recorded >in the /dev inode for it. ... It seems to me that this is a cleaner >solution all around. I remain unconvinced. It is certainly an intriguing idea, and not entirely without precedent (we have a local kernel hack that already puts things into the disk block fields of /dev inodes). It has some definite advantages: - the number of partitions per drive is not fixed; - one can record striping information cleanly; - it takes very little driver code. It also has some definite disadvantages: - the number of partitions per drive is not fixed; - there is a bootstrap problem (avoided by compiling in the root partition info); - it does little for removable packs (indeed, it is quite possibly harmful in such cases); - it discourages sharing the information among operating systems (VMS to read Unix /dev directories anyone?). I still believe that the disk layout is a property of the disk pack, not of the file systems mounted thereon. There is certainly some crossover, though. Perhaps the information should be in several places, and cross-verified---though that brings up the question of what to do if the verification fails. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
davest@tektronix.UUCP (10/10/86)
In article <7195@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >They had the right idea: the size and disk location of each partition >is recorded in the /dev inode for it. This does have a certain appeal to it. After all, we really are talking about an attribute of the thing you are opening or mounting, so it makes sense to put it there. The disadvantage of this is that inodes contained in /dev are not in some fixed location on the disk. It makes sense to put the partitioning information in some location where a stanadlone utility, for example, can find it without needing to know anything about the filesystem. In this way, one could write a standalone facility to repair the partition information in case of damage. Alternatively, one might wish to establish the partition sizes and location as part of a disk initilization operation and thus before the root partition gets made. Another disadvantage to putting the information in the on-disk inode is that you add another bit of fluff to the inode structure that will only be used by a very small portion of the total number of the system's inodes (of course, if we're talking aesthetics, an ugly disk label plopped someplace is not very symetrical either). It would certainly be a better alternative to put the information in the /dev inode than in the superblock as has been done in Ultrix. The Ultrix solution is quite prone to lossage due to error (I am used to dd-ing the root partition to a spare `a' partition to use as a shadow root. This is a fine way to clobber the partitioning data you may have already put on that disk in the `a' partition.) However, the best approach to this is one where the partitioning information cannot be destroyed by some inadvertant administrator action that may not be discovered until the next attempted reboot. I dislike hiding the information within another system structure (be it inode or superblock or whathaveyou) that is susceptable to change without realizing the impact. I like the alternative of putting the disk label in a dedicated location on disk and constraining the disk driver so that the sector cannot be written unless it is via an explicit ioctl that orders it. That way, if the sector *does* get written to, at least the person making the change `deserves what they get.' -- David C. Stewart uucp: tektronix!davest Unix Systems Support Group csnet: davest@TEKTRONIX Tektronix, Inc. phone: (503) 627-5418
henry@utzoo.UUCP (Henry Spencer) (10/11/86)
My, this has stirred up some discussion, both in news and in private mail. I've thought about it some more, and would like to slightly revise my previous position... Clearly, the ideal solution is indeed a self-describing disk, in which all information about partitioning is on the disk itself. This is complicated somewhat by things like striping: there isn't necessarily a many-to-one correspondence between filesystems and disks, it can be many-to-many. The solution to this might be to define a larger entity, call it a disk group, with the many-to-one mapping being from filesystems to disk groups, and the partition information being a property of the disk group. Each disk would presumably carry an indication of which part of the group it was. There are some other ramifications, like the problem of sorting out how many filesystems there are on a disk -- having this hardwired into the kernel is inconsistent, since it too is partitioning information. Apart from the substantial complexity of describing partitioning in the presence of things like striping, the big problem is the lack of a standard place to put the information. It's really hard to come up with something that can be fitted onto any disk, especially if more than one system wants to run on it. If we do NOT go for self-describing disks, then I would contend that the inode is the ideal place for the information. Putting it in the driver is silly, since this information isn't particularly device-dependent in the usual sense. (It depends on, e.g., which Eagle is connected, not on whether it's an Eagle or what type of controller it's connected via.) Making it a separate entity within the kernel seems unnecessary. To answer some specific comments: > - there is a bootstrap problem (avoided by compiling > in the root partition info); There has always been a bootstrapping problem: the kernel has to know where the root is. Not even self-describing disks will help this if there is more than one possibility. Using the inode to hold partitioning information doesn't solve this problem, but nothing else does either. > - it does little for removable packs (indeed, it is > quite possibly harmful in such cases); It's no worse than the current situation. Indeed it is substantially better, since one can just use a different set of /dev entries for access to the pack, rather than having to recompile the kernel. > - it discourages sharing the information among operating > systems (VMS to read Unix /dev directories anyone?). VMS to read Unix partitioning information anyone? That's just as hard to believe. > ... It makes sense to put the partitioning > information in some location where a stanadlone utility, for example, can > find it without needing to know anything about the filesystem... This is a valid point. Putting the information in the inodes is no better than the current situation, although I would point out that it's no worse. Sometimes it makes sense to settle for solving some of the problems, rather than trying for all of them. > Another disadvantage to putting the information in the on-disk > inode is that you add another bit of fluff to the inode structure that > will only be used by a very small portion of the total number of the system's > inodes... It doesn't have to make inodes any bigger, since much of the space in a special-file inode is unused anyway. Typically the device number uses 2 bytes of the 40 available. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
mojo@sun.UUCP (10/13/86)
In article <7221@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >To answer some specific comments: > >> - there is a bootstrap problem (avoided by compiling >> in the root partition info); > >There has always been a bootstrapping problem: the kernel has to know >where the root is. Not even self-describing disks will help this if >there is more than one possibility. Using the inode to hold partitioning >information doesn't solve this problem, but nothing else does either. I still believe there is a fundamental bootstrap problem with the inode partitioning approach which you don't get it you do it `right'. In the inode partitioning approach you have to have a file system open (which means you have to know partitioning info) before you can read the inode to get the partitioning info. If the partitioning info is read off of the physical disk and you know which partition you want to use (e.g. the `a' partition), then you don't have any problems. I'm not sure what you are thinking about when you say "more than one possibility", but if you want to boot off something other than the `a' partition, then the boot procedure should be set up to allow it and that's it. If you are talking about changing the partitioning dynamically, then you have to make sure that file systems are remade if the partition is shrinking. In any case having a standalone program that changes the partitioning info per disk allows for additional flexibility. I don't believe that there "has always been a bootstrapping problem" on all systems. >> - it does little for removable packs (indeed, it is >> quite possibly harmful in such cases); > >It's no worse than the current situation. Indeed it is substantially >better, since one can just use a different set of /dev entries for access >to the pack, rather than having to recompile the kernel. Again - what is your model of the world? The current Vax 4.x disk layout is *not* what everyone has. I agree that having to recompile the kernel for these types of things is wrong, wrong, wrong. Having partitioning info read per disk handles things like removable packs correctly. >> - it discourages sharing the information among operating >> systems (VMS to read Unix /dev directories anyone?). > >VMS to read Unix partitioning information anyone? That's just as hard to >believe. I disagree with the use of the word "just" here - it is no where as hard of a problem. While having VMS read Unix directory formats is really wrong, having more than one OS or file system type understanding disk labeling and partitioning is possible and seems usable. Why go with a layout that will forever precludes sharing disk labeling/partitioning? While it might seem hard for you to believe that VMS/Unix disk partitioning could happen, I am an optimist and see it differently. If, for example, someone implements a VMS file system type under Sun's vnode as a different file system type, it seems bogus to have a disk which has both VMS and Unix file systems on it to have one file system type or the other control partitioning of the disk. It still seems to me that this is a per disk pack sort of thing at a different level from the file system implementation. >> ... It makes sense to put the partitioning >> information in some location where a stanadlone utility, for example, can >> find it without needing to know anything about the filesystem... > >This is a valid point. Putting the information in the inodes is no better >than the current situation, although I would point out that it's no worse. >Sometimes it makes sense to settle for solving some of the problems, rather >than trying for all of them. Again I disagree as I think you are thinking just about the current Vax Unix situation only. When the partitioning is read off the disk, having the information in the inode seems much worse here. >> Another disadvantage to putting the information in the on-disk >> inode is that you add another bit of fluff to the inode structure that >> will only be used by a very small portion of the total number of the system's >> inodes... > >It doesn't have to make inodes any bigger, since much of the space in a >special-file inode is unused anyway. Typically the device number uses 2 >bytes of the 40 available. Agreed that there are ways to load up the bits. But the point here not the inode size, rather I think it is the inode concept. With your proposed approach you are making making "yet another a special inode type". Gee, we could talk about overloading all 40 bytes for device inodes with "super minor numbers" which can be interpreted all over the OS! The thing that seems to get messy here is where these things are interpreted. The device driver is normally the one interpreting the disk partitioning, yet the file system implementation would seem to be the one looking at the inode partitioning info. It just doesn't seem real clean to me. The inode partitioning approach does have some advantages (personally I think the no hard limit on number of partitions the best one), but overall I think that reading the partitioning information off the disk is a FAR better way to go. Please remember that comparing new partitioning schemes to the current 4.3 scheme isn't the right way to go as that stuff is a mistake in itself. There are other folks that have a more sane approach to these types of problems and that "the current situation" is not always the "partitions compiled in the kernel" scheme. Joseph Moran {ihnp4, decvax, seismo, decwrl, ...}!sun!mojo mojo@sun.COM (or mojo@sun.ARPA)
mangler@cit-vax.Caltech.Edu (System Mangler) (10/26/86)
In article <8102@sun.uucp>, mojo@sun.UUCP writes: > In the inode partitioning approach you have to have a file system open > (which means you have to know partitioning info) before you can read the > inode to get the partitioning info. The only partitioning info you really need to know about the root filesystem is the location of the superblock. The superblock will then tell you everything you want to know about the partition: size, geometry, ... The problem arises earlier in the boot process. The first call to a 4.2bsd disk driver is not an open(), as you might expect; rather, it's an xxsize() call to determine the size of the primary swap partition. Putting the partition info in the inode is a great idea (no limit on the number of partitions) but the bootstrapping problems are real. It is dangerous to have one of your partitions defined separately, e.g. the swap partition defined in the kernel; it causes accidents. And then there's the standalone programs, which need to understand partitions without being required to mount a root filesystem. Looks like we need a "partitions" block, someplace that won't get overwritten. So where? What sector number does Ultrix use? Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speck
henry@utzoo.UUCP (Henry Spencer) (10/27/86)
> I still believe there is a fundamental bootstrap problem with the inode > partitioning approach... you have to have a file system open (which > means you have to know partitioning info) before you can read the inode > to get the partitioning info. If the partitioning info is read off of > the physical disk and you know which partition you want to use (e.g. > the `a' partition), then you don't have any problems... I don't believe > that there "has always been a bootstrapping problem" on all systems. There is no chicken-and-egg problem with inode partitioning: you do bootstrapping the same way most Unixes do it now, i.e. the kernel knows the location of the bootstrap partition. This is a little unclean, but I never claimed that inode partitioning was an answer to all the world's problems -- just some of them. Self-describing disks don't solve all the problems either, since they still have the fundamental bootstrap problem I alluded to, to wit knowing which partition on which drive to boot from. (Yes, Virginia, there are people who have more than one kind of drive, so "drive 0" isn't a sufficient answer.) Self-describing disks are not a panacea for the bootstrap problem. They do simplify the problem of knowing where the chosen partition is, although I would comment that this is seldom much of an issue, since most people put the usual boot partition first on the drive anyway. > >It's no worse than the current situation. Indeed it is substantially > >better, since one can just use a different set of /dev entries for access > >to the pack, rather than having to recompile the kernel. > > Again - what is your model of the world? The current Vax 4.x disk > layout is *not* what everyone has. I agree that having to recompile > the kernel for these types of things is wrong, wrong, wrong. Having > partitioning info read per disk handles things like removable packs > correctly. This was precisely my point -- inode partitioning can handle this situation correctly too. You just need a different set of inodes for a different pack. Not as graceful or as automatic as self-describing disks, but a major improvement on the current situation. > >VMS to read Unix partitioning information anyone? That's just as hard to > >believe. > > I disagree with the use of the word "just" here - it is no where as hard > of a problem. While having VMS read Unix directory formats is really > wrong, having more than one OS or file system type understanding disk > labeling and partitioning is possible and seems usable... I should have been more explicit here. I didn't mean it was unbelievable because there was anything technically hard about it; I meant it is unbelievable because that degree of cooperation from the VMS world is totally implausible. VMS, read *somebody else's* idea of partitioning information? Don't you know that VMS is The Only operating system for the VAX, by royal decree? (You and I, benighted heathens that we are, may not know this, but the VMS group within DEC sure does.) No, there is no real technical reason why different operating systems cannot share partitioning information, but this is an inconsequential argument because the probability of it actually happening to any extent is just about zero. > >It doesn't have to make inodes any bigger, since much of the space in a > >special-file inode is unused anyway. Typically the device number uses 2 > >bytes of the 40 available. > > Agreed that there are ways to load up the bits. But the point here not > the inode size, rather I think it is the inode concept. With your > proposed approach you are making making "yet another a special inode > type"... Nonsense, all I'm doing is adding a few more fields to an *existing* special inode type, to wit the block-special-file inode. > ... The thing that seems to get messy here is where these things > are interpreted. The device driver is normally the one interpreting > the disk partitioning, yet the file system implementation would seem to > be the one looking at the inode partitioning info. It just doesn't > seem real clean to me. The most straightforward implementation just remembers the information and passes it to the driver at the right times. The file system implementation doesn't have to know what it means or how to interpret it, any more than it knows how to interpret block numbers as disk addresses. All it knows is "if I hand this to the disk driver, it will do the right things with it". > The inode partitioning approach does have some advantages ... but > overall I think that reading the partitioning information off the disk > is a FAR better way to go. Please remember that comparing new > partitioning schemes to the current 4.3 scheme isn't the right way to > go as that stuff is a mistake in itself. There are other folks that > have a more sane approach to these types of problems... Overall, I agree that reading the partitioning information off the disk is a better way to go. *If* you can swing it. It's not easy to retrofit into existing implementations that just don't *have* any convenient place to put the information on the disk. Inode partitioning lacks that problem. It provides fewer benefits, but at potentially lower costs for existing systems. I agree that self-describing disks are preferable for new work. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
dave@murphy.UUCP (H. Munster) (10/28/86)
I think that the partition info belongs on the disk, along with anything else needed to mount or boot off of a disk. This will make life much easier and safer for folks who use removable packs, and for those who have to change their partitioning frequently. A partition table should contain the following: disk geometry info (sectors/track, tracks/cyl, etc) location of partition boundaries (obviously) location of bad block table and spare tracks, and (maybe) a flag indicating what sort of bad block replacement algorithim is in use (mapping to spare sector, sector "slipping", etc) a flag for each partition indicating what sort of thing the partition is (BSD partition, SYS-V partition, raw data, swap, etc). The mount routines should mount only partitions of the proper type, and the swapon routines should refuse to start swapping on a partition that isn't designated as a swap partition. Also, standalone disk diags that scribble on a portion of the disk to test write functions should issue a "are-you-sure-you-want- to-do-this" prompt if the area being used isn't a swap partition. a volume or set number, for implementing multivolume file systems (for instance, Chris Torek's striping setup). (perhaps) a partition label for each partition ECC code (or even a backup copy of the table if there's room) Resist the temptation to put info relating to mountable file systems in the partition table. Such info belongs in the file system's super block. About the space problem: Is it safe to assume that every disk used in the UN*X world has at least 8 512-byte sectors per track? If so, there should be at least 2k bytes for the table, as I've never seen a first-level bootstrap that was larger than 2k (except for the VMS boot on 780's, but it loads that off of a floppy). Now, a related subject: In article <8102@sun.uucp>, mojo@sun.UUCP (Joseph Moran) types: >In article <7221@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>To answer some specific comments: >> >>> - there is a bootstrap problem (avoided by compiling >>> in the root partition info); >> >>There has always been a bootstrapping problem: the kernel has to know >>where the root is. Not even self-describing disks will help this if >>there is more than one possibility. Using the inode to hold partitioning >>information doesn't solve this problem, but nothing else does either. > >I still believe there is a fundamental bootstrap problem with the inode >partitioning approach which you don't get it you do it `right'. In the >inode partitioning approach you have to have a file system open (which >means you have to know partitioning info) before you can read the inode >to get the partitioning info. If the partitioning info is read off of >the physical disk and you know which partition you want to use (e.g. >the `a' partition), then you don't have any problems. I'm not sure >what you are thinking about when you say "more than one possibility", >?_but if you want to boot off something other than the `a' partition, >then the boot procedure should be set up to allow it and that's it. I think what he means is the old problem of "how does the kernel know what drive it was booted from?" Well, on Gould machines, the console bootstrap sequence leaves the boot device # in a register, and locore.s fetches it, converts it to a major/minor number, and feeds it to the init routine. Therefore, there's no need for specifying the root device at sysgen time, and no problem with moving a pack that contains a root to another drive and booting it. (In the standard BSD setup, you have to specify the root and swap devices at sysgen, and if you move the root pack to another drive and try to boot it, it may overwrite data on the original drive when it tries to turn on swapping.) Other hardware developers should provide this kind of feature. "Fine and well," you say, "where does that leave the rest of us with Vaxen or whatnot?" Well, you could have a startup routine that is called at cold-start time which goes through the CSR's of each drive that the kernel knows about and looks for the one that has an interrupt request outstanding (assuming that the initial boot is done with interrupts disabled or blocked). I realize that this would be a problem since it's done way before autoconfig, but it's something to think about. A P.S.: is there a great demand for the ability to boot from partitions other than the 'a' partition? It would be nice, but I personally could live without it if it means major work on the bootstrap sequence. Does anyone out there need this? Another subject: >>> - it discourages sharing the information among operating >>> systems (VMS to read Unix /dev directories anyone?). >> >>VMS to read Unix partitioning information anyone? That's just as hard to >>believe. > >While it might seem hard for you to believe that VMS/Unix disk >partitioning could happen, I am an optimist and see it differently. Although I too would like to see more operating systems able to coexist on a single disk, I just thought I'd point out that, currently, VMS has no concept of disk partitioning, and there doesn't seem to be a great demand among VMS users for it. (That's a flame for another article...) Finally: I think that a good access method for reading/modifying partition and bad block tables is to set up special partitions (and minor numbers) for them (e.g., the bootstrap/partition table area is the 'x' partition, and the bad block table is the 'y' partition). This way, a utility that reads or modifies the partition table can just open a raw device (say "/dev/rdk0x") and use ordinary reads and writes; I'd prefer this to turning another set of ioctl's loose in the world. Of course, none of the ordinary partitions should include either of these areas (not even the 'c' partition). Thoughts? --- It's been said by many a wise philosopher that when you die and your soul goes to its final resting place, it has to make a connection in Atlanta. Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt or ...!ucf-cs!novavax!houligan!dcornutt ARPA: wait a minute, I've almost got it... "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
mac@esl.UUCP (10/29/86)
In article <1073@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: >In article <8102@sun.uucp>, mojo@sun.UUCP writes: >> In the inode partitioning approach you have to have a file system open >> (which means you have to know partitioning info) before you can read the >> inode to get the partitioning info. > > >The problem arises earlier in the boot process. The first call to >a 4.2bsd disk driver is not an open(), as you might expect; rather, >it's an xxsize() call to determine the size of the primary swap >partition. > >Putting the partition info in the inode is a great idea (no limit >on the number of partitions) but the bootstrapping problems are real. >It is dangerous to have one of your partitions defined separately, >e.g. the swap partition defined in the kernel; it causes accidents. I remember beta testing a DG-UX system which you could tell, in the config file, the size you wanted the swap space to be. You could tell it any number, but it used 70,000 blocks. Made life real difficult if you tried to start /usr right after swap, and you spec'ed swap at < 70,000 blocks... we would bring it up single user, then quick adb the kernel. Life in the fast lane... -- ------------------------------------+ | Michael Mc Namara | | ESL Incorporated | | ARPA: mac%esl.UUCP@ames.ARPA | ------------------------------------+----------------------->[]
chris@umcp-cs.UUCP (Chris Torek) (11/03/86)
In article <1073@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: >Putting the partition info in the inode is a great idea (no limit >on the number of partitions) but the bootstrapping problems are real. ... >Looks like we need a "partitions" block, someplace that won't get >overwritten. So where? What sector number does Ultrix use? Ultrix uses the last sector in the first superblock, or in other words sector 31. This turns out to be bad for a number of reasons; the consensus for 4.4 appears to be to use block 0, and just hope that no one ever needs more than $k$ bytes of boot code ($k$ is currently 64, which seems rather small to me). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
henry@utzoo.UUCP (Henry Spencer) (11/06/86)
> ... A partition table should contain the following: > > ... (maybe) a flag indicating > what sort of bad block replacement algorithim is in use ... > > a flag for each partition indicating what sort of thing the partition is > (BSD partition, SYS-V partition, raw data, swap, etc)... I implore anyone doing something like this to implement those "flags" as space for a short character string, *not* as a one-byte magic number. Using character strings doesn't eliminate the administrative problems of making sure that the same code doesn't get used for two different things, but it makes them a whole lot less likely. Note also that 4BSD filesystems can be 4KB or 8KB, SysV filesystems can be 512B or 1KB, and V8 filesystems can be 1KB or 4KB... to mention just a few variations that should be described. > a volume or set number, for implementing multivolume file systems (for > instance, Chris Torek's striping setup). This is more complex than it looks; striping requires more information than that, at least in principle. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry