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

Re: Ext3 partition not appearing in df output



On Oct 30, 2001  07:52 -0500, Theodore Tso wrote:
> On Tue, Oct 30, 2001 at 11:36:17AM +0000, Andries Brouwer cwi nl wrote:
> > > you could just have it dispatch to the right version of /sbin/mount.*
> > > by looking at the type information in /etc/fstab
> 
> Well, "auto" was used because there was no other way of doing what
> users want to do, which is to get the automatic ext3/ext2 fallback
> behaviour.

Well, looking at the comments in the mount code, it looks like mount
_already_ will try to run /sbin/mount.ext3 (and strace confirms it).
It also seems it will try to run /sbin/mount.auto as well.

> And my suggestion of making /sbin/mount.auto handle hueristics was
> because that way Andreas Dilger's liblkid library could handle all of
> these huersitcs in a common way, which might be best both from a code
> maintenance point of view, and because you're not particularly
> comfortable with this approach in the first place.  
> 
> (You can make the huersitcs approach of identifying filesystems work
> but it is ugly.  However, it is possible to make its reliability
> asymptotically reach 100% by putting in more sophisticated filesystem
> checks into a library like libblkid.)

With the above "revelations", it is perfectly possible to "fix" any ext3
issues with a few simple shell scripts.  We make mount.ext3 first check
for ext3 in /proc/filesystems (and try modprobe ext3 if not).  If ext3
is not available, fall back to calling mount.ext2 (for consistency's sake
instead of just mounting ext2 directly).  We print a warning in the case
that ext3 is unavailable, but fail outright if it IS available but the
mount failed.

Having mount.ext3 handle the details also removes any fs-specific
knowledge from mount (the fact that it should fall back to trying ext2
if it doesn't work).  This is analogous to the fact that fsck.ext3 can
check an "ext2" filesystem as well.


We can make mount.auto either be a binary which uses libblkid to do the
detection directly, or just be a shell script which calls the "blkid"
user program to determine the filesystem, which would look like:

$ blkid -d /dev/vgboot/lvboot -s TYPE
/dev/vgboot/lvboot: TYPE="ext2"

so we can easily parse this to determine the type directly.  This means
we _could_ strip all of the fs detection code out of mount, and any mount
without a type defaults to type "auto" if it is not found in /etc/fstab.

The only minor drawback of doing it with an external mount.auto program
(as opposed to doing fs type detection directly in mount) is that mount
will need libblkid to do LABEL and UUID detection anyways, so we have
_already_ done content detection at that time and having an external
program do it again would just be bloat.

Cheers, Andreas

PS - I added most of the fs types supported by mount into libblkid
     yesterday evening.  Most were one-liners (i.e. only do a single
     magic number detection, nothing else), except for hfs, which
     "needs" to check the blocksize (I'm not sure I agree with this
     because if the kernel code ever supports other than 512-byte
     blocks we will need to change the library/mount, ugh).  One
     fs that is missing is ADFS, which apparently has no magic at
     all (AFAICS), kind of ugly.  I think mount is also ignoring a
     bunch of endian issues, but it is hard for me to test.  I will
     post both soon.
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/





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