DragonFly BSD
DragonFly submit List (threaded) for 2004-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: patch to mount(8) to support optional filesystem mounts


From: Chris Pressey <cpressey@xxxxxxxxxxxxxxx>
Date: Fri, 23 Jan 2004 12:32:58 -0800

On Fri, 23 Jan 2004 11:26:04 -0800 (PST)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> :Matthew Dillon wrote:
> :
> :>     Hmm.  Well, a better solution might be to not mount those
> partitions:>     from /etc/fstab at all but instead mount them in
> /etc/rc.local, or:>     create a /usr/local/rc.d script, which can do
> more sophisticated:>     checks to determine which drive you've loaded
> into the bay.:
> :It may enable more sophisticated setup, but having all mounting
> potentially:mentioned in only one place - /etc/fstab - might be nice
> from an:administrative viewpoint.  Plus, that doesn't exclude going to
> :a /usr/local/rc.d script when a more fancy setup is desired.
> 
>     Well, then just specify the mounts as 'noauto' in /etc/fstab and
>     write an RC script to optionally mount them.  Maybe
>     'noauto,rcmount'.  Then put the basics in the rc file so it works
>     as you expect, and we can commit that.  This would be more
>     flexible then adding an optional option to mount.
>
>     Or even better, make it so you can name groups of mounts.  So in
>     the fstab you would use noauto,rcmount1 for the entries
>     correspdonding to removal disk #1, and noauto,rcmount2 for the
>     entries correspdonging to removal disk #2.

Well, I started thinking about it harder and came up with something a
bit more radical: don't use "mount -a" at all in the boot process
(effectively deprecating the auto/noauto options.)

Instead, make /etc/rc.d/mountall a sort of meta-script that doesn't do
much beyond "REQUIRE: mount_usr mount_var mount_proc mount_others"
Where each of these subsidary scripts just mounts a particular device. 
(Actually, that might be a bad way to split it up; maybe more along the
lines of permanent/temporary, but whatever.)

The motivation for doing it this way would be to let it be really
sophisticated - you might want to try to mount a filesystem only if a
certain file can't be found on some other filesystem (which itself must
first be mounted.)  So the mount points would follow a dependency graph
not unlike rcng itself, and simply trying to mount each of them in an
iterative loop like "mount -a" seems a little quaint.

There's still a problem, though: you could very well want to specify two
different devices for the same mount point in the fstab.  I don't think
the fstab was ever designed for that; I think the assumption was that it
would hold a unique list of (essentially) permanent devices.

"Overloading" the mount points could very well confuse anything that
looks in the fstab (mount, umount and possibly fsck or whatever it is
that looks at the last two columns in the fstab.)

Maybe one way to address this is to support multiple fstabs, with
command line options to mount/umount/fsck for which fstab to use?

Sorry for the verbose brain dump, still trying to clarify my thoughts.

-Chris



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]