Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!rutgers!husc6!panda!genrad!decvax!decwrl!sun!mojo From: mojo@sun.UUCP Newsgroups: net.unix-wizards Subject: Re: Location of partition table on disk Message-ID: <8102@sun.uucp> Date: Mon, 13-Oct-86 03:59:28 EDT Article-I.D.: sun.8102 Posted: Mon Oct 13 03:59:28 1986 Date-Received: Tue, 14-Oct-86 06:21:51 EDT Reply-To: mojo@sun.UUCP (Joseph Moran) Organization: Sun Microsystems, Inc. Lines: 107 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)