On Mon, May 06, 2013 at 07:38:23PM -0500, Eric Sandeen wrote:
> On 5/6/13 7:34 PM, Dave Chinner wrote:
> > On Tue, May 07, 2013 at 10:23:14AM +1000, Dave Chinner wrote:
> >> On Mon, May 06, 2013 at 04:48:39PM -0500, Eric Sandeen wrote:
> >>> On 5/6/13 3:49 PM, Eric Sandeen wrote:
> >>> ...
> >>>
> >>>> Interesting, so [mount] really does try to mount by successive fs types.
> >>>>
> >>>> I wonder when that behavior changed (my util-linux-ng 2.17 on RHEL6 doesn't do this)
> >>>>
> >>>> I'll take a look.
> >>>
> >>> Just to satisfy my curiosity:
> >>>
> >>> commit c6c98f93f5e4b3fb9a8b51ed2ef9967793df7b1c
> >>> Author: Karel Zak <kzak@xxxxxxxxxx>
> >>> Date: Mon Mar 15 13:46:43 2010 +0100
> >>>
> >>> mount: report ambivalent FS detection, improve brute force detection
> >>>
> >>> The ambivalent probing result should be properly reported and user
> >>> should be informed that the problem is possible to bypass by "-t
> >>> <type>" or resolved by wipefs(8).
> >>>
> >>> The mount(8) command uses a brute force stage (calls mount(2) for all
> >>> /{proc,etc}/fylesystems) if there is not any other way how to detect
> >>> the filesystem type. The brute force stage should not be restricted by
> >>> libblkid. It's possible that libblkid is not able to detect slightly
> >>> corrupted filesystem, but kernel is able to mount such filesystem.
> >>>
> >>> Note that the brute force stage should not be used if libblkid returns
> >>> ambivalent probing result. In this case user's intervention is required
> >>> (e.g. mount -t <type>).
> >>>
> >>> Reported-by: Mike Frysinger <vapier@xxxxxxxxxx>
> >>> Signed-off-by: Karel Zak <kzak@xxxxxxxxxx>
> >>>
> >>> So we're getting into xfs mount with an actual "-t xfs" equivalent,
> >>> and not going down the "silent" paths.
> >>
> >> That's just completely broken mount behaviour. Probing is supposed
> >> to be *silent*, and this is just downright obnxious. Here's what I
> >> get in my log after doing this:
> >>
> >> # dd if=/dev/zero of=/dev/vdb bs=512 count=1
> >> # blkid -g
> >> # mount /dev/vdb /mnt/scratch/
> >> mount: you must specify the filesystem type
> >> $ dmesg
> >> ......
> >> [83182.775467] REISERFS warning (device vdb): sh-2021 reiserfs_fill_super: can not find reiserfs on vdb
> >> [83182.778473] EXT3-fs (vdb): error: can't find ext3 filesystem on dev vdb.
> >> [83182.781135] EXT2-fs (vdb): error: can't find an ext2 filesystem on dev vdb.
> >> [83182.783524] EXT4-fs (vdb): VFS: Can't find ext4 filesystem
> > ....
> >
> > BTW, strace indicates that MS_SILENT is not being used during brute
> > force mounts:
> >
> > # strace -vx mount /dev/vdb /mnt/scratch/ 2>&1 |grep ^mount
> > mount("/dev/vdb", "/mnt/scratch/", "reiserfs", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> > mount("/dev/vdb", "/mnt/scratch/", "ext3", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> > mount("/dev/vdb", "/mnt/scratch/", "ext2", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> > mount("/dev/vdb", "/mnt/scratch/", "ext4", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> > ....
> >
> > So this really looks like a bug in mount, not the filesystem handling
> > of slient mounts...
>
> Hm, good point, I forgot that mount could set MS_SILENT. . .
>
> But still:
>
> Do we really *ever* need this level of info when xfs discovers EWRONGFS?
Say, like when the autoprobe mount fails, and so you do a mount -t
xfs to find out why it failed?
Perhaps the magic number is just fine (so blkid OKs it) and so the
silent mount turns into a proper "noisy" mount and then we find a
version number in the superblock that is not supported. That'll also
throw a EWRONGFS error, and in that case the extra output will tell
use exactly what went wrong.
Besides, the quiet verify path does not do an initial CRC check, and
so if we do get a superblock CRC failure, it will dump something
like this anyway....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
