Date: Wed, 1 Nov 1995 15:06:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, grog@lemis.de, hackers@FreeBSD.org Subject: Re: More nits Message-ID: <199511012206.PAA00366@phaeton.artisoft.com> In-Reply-To: <1330.815259112@time.cdrom.com> from "Jordan K. Hubbard" at Nov 1, 95 12:51:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't understand. You want it to mount a non-existant drive?
>
> It's easy to understand.
>
> You have a CDROM mount in your fstab. It's not using "noauto."
>
> 99% of the time, you have a CD in there and everything's happy. 1% of
> the time you don't, and the machine falls over if it needs to reboot
> unattended. This is EVIL, Terry. It's totally unnecessary for it to
> do that and certain mount failures should NOT NOT NOT be counted as
> "fatal" errors. Sure, if I can't mount /usr then it's a pretty fatal
> condition. If I can't mount my GIFS Galore CDROM, then it's most
> definitely not!
Clearly if you put it in your fstab without "noauto", you thought the
"GIFs Galore CDROM" was critical to your use of the system.
8-).
The point is, how can the system differentiate between "/cdrom" and
"/usr" failing to mount? Without "/usr", you don't have your shared
libraries or libexec, and it's just as fatal.
So while I agree that it should fall over more gracefully, I'd have
to argue that it *should* fall over.
> I know, you personally are probably running some weird system where
> everything except the kernel is linked to the CDROM and it *is*
> a fatal error, but we're not talking about you - we're talking about
> the other 99.99% of users out there for whom this behavior is simply
> a pain in the ass. I hardly see that we need to reinvent the entire
> removable media subsystem in order to fix this particular nit! :-)
Actually, I'm running a system where if a device is detected, it's passed
to a mount, and each file system is asked if it wants the device, and if
it does, then it's mounted relative to the value in the /etc/fstab, or
if it's not in the /etc/fstab, it's not mounted.
So the /etc/fstab is a device-name-to-mount-point mapping table which
is used if a device is detected, not a list of operations that need to
be performed.
This means that the remount facility has to unexport the previous mount
for an overlapping mount, which happens to fix the mount -a remount
bug as well (it's only a feature if the behaviour is expected -- the
"-a" option from a user expects to mount unmounted things in the fstab,
not remount mounted ones over themselves).
> > > I think you're right. Hmmm. I will have it ask you when you leave
> > > the editor, 'k? What do the others think?
> >
> > I think the whole logical volume device mapping is going to change
> > under devfs. I think it *doesn't* belong in the partitioning tool.
>
> Excuse me?! What does adding a boot manager have to do with logical
> volume device mapping?
It has to do with what the hell belongs in a partitioning tool, and
writing a boot manager is one of the things that damn well doesn't.
If logical partitioning is handled by fdisk, the more logical
partitioning interface mechanisms you support, the more of a frob
writing the MBR with fdisk becomes. It becomes a piece of crap
when you port your tools to a non-DOS platform.
Actually, you want an imposed heirarchy that results from iterating
the device file system for the types of devices desired on a bredth-first
basis.
Consider:
I have raw devices that map to targets and LUNs. This is the native
driver presentation to the kernel. We will ignore issues of media
perfection, volume spanning, and disk striping for the purposes of
this discussion.
We have a list of logical device drivers. We ask the logical device
drivers iteratively if they want a device until they all answer "no".
Consider the following set of logical devices:
1) DOS Partitioning
2) DOS Extended partitioning
3) BSD Extended partitioning (disklabel)
Say we have a device "wd0".
Say it has 3 DOS partition table entries:
i) DOS primary partition
ii) DOS Extended partition
iii) FreeBSD Extended partition
Say the DOS extended partition has a DOS secondary paritition on it
Say the BSD Extended partition has the "slices" (stupid name) a,b,e, and f
(stupid out of sequence letters) on it
So we have:
,-------------------------- exported into fs namespace by devfs
| ,------------------ exported into fs name space by device driver
| | ,-- exported into fs name space by logical devices
| | |
|<---->|<------------->|<----------->|
/dev devfs
/wdc0 first wd controller
/0 first disk on first wd controller
/p1 DOS primary partition on first disk
/p2 DOS extended partition on first disk
/p1 DOS secondary partition on extended
partition on first disk
/p3 BSD extended partition on first disk
/a Slice 'a' on BSD extended partition
/b Slice 'b' on BSD extended partition
/e Slice 'e' on BSD extended partition
/f Slice 'f' on BSD extended partition
Now ...how do I make an "fdisk" that can handle all this?
I do it by querying the list of logical partitioning mechanisms that
are available to me and presenting a map for them, as well as a mechanism
for implementing an instance of them.
In memory in the devfs, each of these are stored as a reference to the
real physical device or the previous logical device with an offset and
a length (domain + range) which the device operates on (gee, note how
cleverly this allows us to collapse layers when no physical translation
occurs, as well as how cleverly this allows us to prevent the layering
collapse when we want to support striping, volume sets, spanning, and
media perfection... note how the media perfection is useful for both
disklabel and superblock contents, unlike the stupid bad144 stuff).
Gee, it would be nice to put the OS dependent perititioning mechanism
in to nice, logically seperate, OS dependent bundles like this so we
can mount OSF and Sun and JFS disks on Alpha, SPARC, and PPC hardware.
How do you tell a logically layered device from one that isn't? You
call getdirentries(2) on it, and if you get an ENOTDIR, it's a terminal
node.
Note that there is no reason you can't open/read/write/ioctl intermediate
devices: after all, in devfs, they have a vnode associated with them: the
calls don't give a damn if the vnode type is VDIR or not.
> Terry's off in space again!! :-)
Hardly. It's Jordan who wants to jam a PC specific, single logical
layer specific *wart* into the nice, clean, system independent fdisk
interface that would otherwise work for AIX, SunOS, OSF/1, and other
OS's so we can *FINALLY* abstract the idiotic, limited, BIOS geometry
dependent DOS partition crap.
The correct place to write the boot code is to /dev/wdc0/0 using some
generic piece of code that dlopen's a logical device specific object
module and references logical device specific data (like an MBR image,
for instance).
Barring doing it the correct way, it should be a seperate program
that can tell the devfs to rescan the device from the affected layer
up -- you need that anyway to support insertion of removable media.
Please, please do not put it into a frob that will just have to be
ripped right back out and made standalone again.
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?199511012206.PAA00366>