[BusyBox] Filesystem detection in mount & lazy unmount

[Chris Spiegel]

On Tuesday 12 July 2005 11:49 am, Rob Landley wrote:
> On Tuesday 12 July 2005 03:24, Chris Spiegel wrote:
> > 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.)

I'm not trying to beat this topic into the ground -- I'm just making sure 
we're talking about the same thing.

It's not "we don't support Reiser 4 but we think that's what it is."  It's 
"The current state of the kernel doesn't support Reiser 4, but that's what it 
is.  Let's try mounting as such and get the kernel to load the proper 
module."  Assuming kmod, of course.

The advantage over /proc/filesystems is that it can mount filesystems whose 
modules aren't yet loaded, because it really isn't important what the kernel 
*currently* supports, it's important what it *may be able to* support.  The 
advantage over /etc/filesystems isn't quite as clear.  It takes burden off 
the end-user (which may be a disadvantage depending on your point of view) 
and it doesn't require many filesystems to be tried, and their modules 
loaded.  Again, I understand that it's not a revolutionary change 
from /etc/filesystems.

> > 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?

You cut off the most important part of the example! =)

> > It knows to try xfs, and, moreover, the module gets loaded.

I wasn't surprised that I got the message "You didn't specify a filesystem."  
I was showing that mount was able to determine what it was supposed to do all 
by itself.  The module was loaded, the filesystem was mounted.  In fact, that 
message would have popped up even if the filesystem were listed 
in /etc/filesystems -- util-linux mount checks the filesystem type before it 
checks /etc/filesystems.  It displayed the message because I used the -v 
flag.

>
> 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...

Yes, of course.. That was the reason I sent my initial mail, to find out what 
the consensus on this feature was.  If it winds up not being in busybox, I 
will survive, because a static mount from util-linux is not very big and 
won't kill my initrd.

Chris