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 16:48:39 -0500 [thread overview]
Message-ID: <51882537.6070904@sandeen.net> (raw)
In-Reply-To: <51881750.3090309@sandeen.net>
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.
I'll send the patch.
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-05-06 21:48 UTC|newest]
Thread overview: 17+ 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
2013-05-06 21:48 ` Eric Sandeen [this message]
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 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=51882537.6070904@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox