Re: Internal error xfs_sb_read_verify at line 726

[Dave Chinner <david@fromorbit.com>]

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@redhat.com>
> > 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@gentoo.org>
> >     Signed-off-by: Karel Zak <kzak@redhat.com>
> > 
> > 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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs