[BusyBox] Filesystem detection in mount & lazy unmount

[Rob Landley]

On Tuesday 12 July 2005 03:24, Chris Spiegel wrote:
> On Tuesday 12 July 2005 12:04 am, you wrote:
> > On Monday 11 July 2005 17:06, Chris Spiegel wrote:
> > > It's true that /etc/filesystems can sort of take the role of automatic
> > > filesystem detection.  My goal as a lazy end-user, though, is to do as
> > > little as humanly possible to get my system working -- currently I have
> > > an initrd that, among other things, doesn't need to be told the root
> > > filesystem type, and if I happen to change it I won't have to make sure
> > > that a text file is up to date, because I'm using util-linux's mount. 
> > > Of course, getting to my goal of lazy end-user may include lots of work
> > > hacking code but I don't mind that for some reason.  :)
> >
> > The way automatic filesystem detection normally works is that it tries
> > all the various filesystems the kernel supports in order, and takes the
> > first one that doesn't fail.  If this doesn't successfully mount the
> > filesystem, then the kernel doesn't support it.
>
> Well, in recent util-linux releases, mount has the ability to do even
> better than just trying known filesystems in order.  It will do various
> checks on the partition to see if it sees any magic numbers of filesystems
> that it knows.  This way, even if the module isn't loaded and no
> /etc/filesystems exists, it still tries to use a particular filesystem,
> causing the module to be loaded.

So you've gained the ability to say "we don't support Reiser 4, but we think 
that's what it is".  I fail to see the improvement.

You've already got to parse /proc/filesystems in order to see what the kernel 
supports.  Adding /etc/filesystems to trigger module loads means you loop 
over two filenames and perform the same processing.  (At least in my rewrite 
it does.)  The amount of code this adds is _tiny_.

I fail to see how adding a magic number database to identify filesystems the 
kernel doesn't support improves matters.  (If I wanted to get really fancy I 
could write a script to automatically synthesize /etc/filesystems 
from /lib/modules/`uname -r`/kernel/fs, but that seems kind of silly.)

> For example, on my testing system, I have an XFS filesystem on /dev/hda1. 
> XFS support is built as a module.  If I do:
> mount -v /dev/hda1 /mnt
>
> I get:
> mount: You didn't specify a filesystem type for /dev/hda1
>        I will try type xfs

Because it's not in /etc/filesystems.

This infrastructure has been there for how many years now?

> It knows to try xfs, and, moreover, the module gets loaded.
>
> This code can be seen in util-linux 2.12q in mount/mount_guess_fstype.c. 
> It uses detection from libblkid if it's available, otherwise it has builtin
> filesystem-guessing code.
>
> It's a generalized version of this code (by SGI for their libdisk) that I
> mentioned in my initial email, whose compiled size on my system is 5K.  So
> it's really not a huge space waster and it gets around having to maintain
> an /etc/filesystems -- although to be fair it does this by essentially
> putting a "more efficient" /etc/filesystems in the mount program itself.

At the very least, wait until I get my mount rewrite in before submitting a 
patch, ok?  The hopefully last repair to my laptop (replacing the screen so 
the yellow line goes away) has been done, and hopefully it's going to work 
consistently now.  I'll try to get you something to work with soon...

> Chris

Rob