[BusyBox] Filesystem detection in mount & lazy unmount

Rob Landley rob at landley.net
Tue Jul 12 23:48:00 UTC 2005


On Tuesday 12 July 2005 18:25, Chris Spiegel wrote:
> > 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.

Which is what /etc/filesystems is for.  It lists the filesystems whose modules 
might not currently be loaded, so that module can be loaded, try to attach to 
the filesystem, and if not its reference count decreases and the module gets 
unloaded again.

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

It moves hardwired knowledge about what filesystems are supported into the 
mount command, meaning you have to patch mount if you want to use squashfs as 
a module.  (And the patch is highly non-obvious since you have to figure out 
what constitutes quashfs detection magic, whereas adding the name 
to /etc/filesystems isn't brain surgery.)

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

We've got infrastructure to do this now.  I'm curious what the advantage of 
your method is supposed to be?

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

For the filesystem types it has hardwired into it.

If you were advocating making "file" be able to identify paritition formats, 
and having mount call file if it were loaded in, that I could almost see.  (I 
tried file and it just said "block device", which is a fairly stupid behavior 
since I could have figured that out with the ls command.  I call file when I 
want to know what's _in_ it.)

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

As far as I can tell, it's not "util-linux", it's "sgi's nonstandard patched 
util-linux", correct?

> Chris

Rob



More information about the busybox mailing list