Re: Internal error xfs_sb_read_verify at line 726

[Eric Sandeen <sandeen@sandeen.net>]

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

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?

-Eric

> Cheers,
> 
> Dave.
> 

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