Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.unix-wizards Subject: Re: Location of partition table on disk Message-ID: <7221@utzoo.UUCP> Date: Fri, 10-Oct-86 17:22:26 EDT Article-I.D.: utzoo.7221 Posted: Fri Oct 10 17:22:26 1986 Date-Received: Fri, 10-Oct-86 17:22:26 EDT References: <7473@sun.uucp> <15583@mordor.ARPA> <1173@hoptoad.uucp> <7195@utzoo.UUCP>, <8759@tektronix.UUCP> Organization: U of Toronto Zoology Lines: 72 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