Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!rutgers!clyde!cuae2!gatech!akgua!codas!peora!ucf-cs!novavax!houligan!dave@murphy.UUCP From: dave@murphy.UUCP (H. Munster) Newsgroups: net.unix-wizards Subject: Re: Location of partition table on disk Message-ID: <131@houligan.UUCP> Date: Tue, 28-Oct-86 12:02:08 EST Article-I.D.: houligan.131 Posted: Tue Oct 28 12:02:08 1986 Date-Received: Mon, 3-Nov-86 21:15:28 EST Organization: Gould Electronics, Ft. Lauderdale, Florida. Lines: 117 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."