Date: Thu, 4 Jul 1996 13:06:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joelh@gnu.ai.mit.edu Cc: terry@lambert.org, jmb@freefall.freebsd.org, tom@sdf.com, jgreco@brasil.moneng.mei.com, root@friday.keanesea.com, hackers@FreeBSD.org Subject: Re: What is the best way to setup a drive Message-ID: <199607042006.NAA13455@phaeton.artisoft.com> In-Reply-To: <199607040616.CAA14851@kropotkin.gnu.ai.mit.edu> from "Joel Ray Holveck" at Jul 4, 96 02:16:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I cringe at the though of another branch of this thread, but here goes... > > > All file systems will have mount point vnode assignments as a result > > of a callback as a result of device probe. > > What about conflicting mount points? Conflicting mount points can be resolved by date. > Or suppose I'm diagnosing a dead /usr disk from another computer... > will I have to worry about my working /usr being overwritten, or > will there be some sort of identification, say, a timestamp written > to all disks late during bootup (after probe and hierarchy fill), > to ensure that they're on the same computer? There's one written already on shutdown. Actually, I was thinking more in terms of "System ID" to resolve the rest (the same function is used by locense managers for key generation). > And if so, how do we handle the whole point of sharing > these? Semaphores, first one to mount stamps? Unmount stamps. For a dead system, the mount/umount times will be earlier than the live system performing the diagnostics, since by definition, you will insert dead system volumes into a live system, instead of the other way around. 8-). > Danger: hair ahead. > > Actually, I don't quite recall the point of your augmented superblocks > to begin with. The point was to move some of the mount options out of /etc/fstab, should it be necessary (as was suggested). Personally, I don't believe it will be necessary. If all mounts are minimal mounts, like / is mounted during boot, then the on disk structure will not be modified, and the issue becomes one of mapping. Consider a DOS system (hold your jeers, please), which has a resource identifier per mountable volume, called "drive letter". I wouldn't go so far as to call it "A:, B:, C:, ...", since I think that's a limited (26, to be exact) soloution. But if you delay the mapping of the FS into the hierarchy until after the creation of a resource ID for it, then you can (fstab) dictate mapping by resource ID. For boot-required resources (like / or /var, if we have our way with /etc), an identifier can be written to the disk. We can identify volumes in our "volume set" by stamping the root create time on our own volumes, or some similar approach, and we can identify system critical mount points by resource identifiers (so if /var was last mounted on /mnt, we know to put it back on /var without being told by an fstab we can't access until we get it mounted). We are going to require some type of volume set identification method in any case to implement multiple volume spanning drivers for the logical-to-physical device translation layer that implements it (currently ccd) in the devfs. Volumes will need to be assembled (part 3 of 4, part 1 of 4, and the last one in the set will cause a call to the devfs_register_dev() to trigger the mount, etc.). > > It is unacceptable for the idea of sharing a read-only > > root among multiple clients, and must be discarded as historical > > cruft, which we may ignore at our leisure. > > Just so long as we don't break any code which depends on said > historical cruft, I'm all for it. I think symlinks brolke V7 "ls"... not to mention long names. 8-). I think the issue is remaining internally consistent and continuing to support programmatic tinterfaces which third parties and ABI services already depend on. We could go back to the previosu (tty) discussion to find an example of where we break ABI compliance (SCO and Solaris both want the partial open hack for running thirs party comm software under ABI emulation), for instance. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607042006.NAA13455>