From: Eric Sandeen <sandeen@sandeen.net>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: xfs@oss.sgi.com
Subject: Re: Internal error xfs_sb_read_verify at line 726
Date: Mon, 06 May 2013 15:49:20 -0500 [thread overview]
Message-ID: <51881750.3090309@sandeen.net> (raw)
In-Reply-To: <20130506195521.GB503@x4>
On 5/6/13 2:55 PM, Markus Trippelsdorf wrote:
> On 2013.05.06 at 14:41 -0500, Eric Sandeen wrote:
>> On 5/6/13 2:26 PM, Markus Trippelsdorf wrote:
>>> On 2013.05.06 at 14:14 -0500, Eric Sandeen wrote:
>>>> On 5/6/13 1:30 PM, Markus Trippelsdorf wrote:
>>>>> On 2013.05.06 at 12:04 -0500, Eric Sandeen wrote:
>>>>>> On 5/6/13 6:27 AM, Markus Trippelsdorf wrote:
>>>>>>> Today I accidentally tried to mount my backup disk at /dev/sdc instead
>>>>>>> of /dev/sdc1 and this is what happened:
>>>>>>>
>>>>>>> ...
>>>>>>> EXT4-fs (sdc): VFS: Can't find ext4 filesystem
>>>>>>> FAT-fs (sdc): bogus number of reserved sectors
>>>>>>> FAT-fs (sdc): Can't find a valid FAT filesystem
>>>>>>> FAT-fs (sdc): bogus number of reserved sectors
>>>>>>> FAT-fs (sdc): Can't find a valid FAT filesystem
>>>>>>> ISOFS: Unable to identify CD-ROM format.
>>>>>>> XFS (sdc): bad magic number
>>>>>>> ffff8800db620000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>>> ffff8800db620010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>>> ffff8800db620020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>>> ffff8800db620030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>>>>> XFS (sdc): Internal error xfs_sb_read_verify at line 726 of file fs/xfs/xfs_mount.c. Caller 0xffffffff8119e5cd
>>>>>>
>>>>>> This seems to be a recent regression.
>>>>>>
>>>>>> Comments above xfs_sb_quiet_read_verify() indicate that this behavior is
>>>>>> to be avoided:
>>>>>>
>>>>>> * We may be probed for a filesystem match, so we may not want to emit
>>>>>> * messages when the superblock buffer is not actually an XFS superblock.
>>>>>>
>>>>>> and it checks for proper magic prior to all the chattiness above int
>>>>>> that function.
>>>>>>
>>>>>> The superblock read is suposed to choose whether to be noisy or not,
>>>>>> in xfs_readsb():
>>>>>>
>>>>>
>>>>> The following patch fixes the issue for me:
>>>>>
>>>>>
>>>>> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
>>>>> index f6bfbd7..db8f27f 100644
>>>>> --- a/fs/xfs/xfs_mount.c
>>>>> +++ b/fs/xfs/xfs_mount.c
>>>>> @@ -721,6 +721,11 @@ xfs_sb_read_verify(
>>>>> }
>>>>> error = xfs_sb_verify(bp);
>>>>>
>>>>> + if (error == XFS_ERROR(EWRONGFS)) {
>>>>> + xfs_buf_ioerror(bp, EWRONGFS);
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> out_error:
>>>>> if (error) {
>>>>> XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
>>>>
>>>> That might make sense, I don't think we need the loudness for EWRONGFS
>>>> no matter how we got there.
>>>>
>>>> But:
>>>>
>>>> Out of curiosity, what was the actual mount command you used? It seems like
>>>> the auto-probing should have set the MS_SILENT flag to avoid this in
>>>> the first place, i.e. we should have gone down the quiet path
>>>> (xfs_sb_quiet_read_verify) and avoided this altogether.
>>>>
>>>> How do you reproduce this?
>>>
>>> I power on the drive and simply run:
>>>
>>> # mount /dev/sdc /mnt
>>
>> Interesting. On my test box, that never even issues the mount syscall,
>> because it uses blkid (I guess) to probe, and finds nothing.
>>
>> Which util-linux do you have?
>
> v2.21.2
>
>> An strace -v of the mount command might be useful.
>
> execve("/bin/mount", ["mount", "/dev/sdc", "/mnt"], [/* 44 vars */]) = 0
...
> stat("/sbin/mount.ext4", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs.d/mount.ext4", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs/mount.ext4", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/usr/sbin/mount.ext4", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> mount("/dev/sdc", "/mnt", "ext4", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> stat("/sbin/mount.vfat", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs.d/mount.vfat", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs/mount.vfat", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/usr/sbin/mount.vfat", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> mount("/dev/sdc", "/mnt", "vfat", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> stat("/sbin/mount.msdos", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs.d/mount.msdos", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs/mount.msdos", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/usr/sbin/mount.msdos", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> mount("/dev/sdc", "/mnt", "msdos", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> stat("/sbin/mount.iso9660", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs.d/mount.iso9660", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs/mount.iso9660", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/usr/sbin/mount.iso9660", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> mount("/dev/sdc", "/mnt", "iso9660", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
> stat("/sbin/mount.xfs", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs.d/mount.xfs", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/sbin/fs/mount.xfs", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> stat("/usr/sbin/mount.xfs", 0x7fff283f7550) = -1 ENOENT (No such file or directory)
> mount("/dev/sdc", "/mnt", "xfs", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
Interesting, so it 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.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-05-06 20:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 11:27 Internal error xfs_sb_read_verify at line 726 Markus Trippelsdorf
2013-05-06 17:04 ` Eric Sandeen
2013-05-06 18:30 ` Markus Trippelsdorf
2013-05-06 19:14 ` Eric Sandeen
2013-05-06 19:26 ` Markus Trippelsdorf
2013-05-06 19:41 ` Eric Sandeen
2013-05-06 19:55 ` Markus Trippelsdorf
2013-05-06 20:49 ` Eric Sandeen [this message]
2013-05-06 21:48 ` Eric Sandeen
2013-05-07 0:23 ` Dave Chinner
2013-05-07 0:34 ` Dave Chinner
2013-05-07 0:38 ` Eric Sandeen
2013-05-07 0:54 ` Dave Chinner
2013-05-07 5:24 ` Mount probing not silent. " Markus Trippelsdorf
2013-05-07 5:24 ` Markus Trippelsdorf
2013-05-07 13:43 ` Markus Trippelsdorf
2013-05-07 13:43 ` Markus Trippelsdorf
2013-05-09 7:29 ` Karel Zak
2013-05-06 21:53 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51881750.3090309@sandeen.net \
--to=sandeen@sandeen.net \
--cc=markus@trippelsdorf.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.