Hi mike,
On Sun, Mar 07, 2010 at 12:39:48AM -0500, Mike Frysinger wrote:
> i have a report where a user has a slightly corrupted filesystem in that
do you know more details? (try BLKID_DEBUG=0xffff /bin/mount ...)
Maybe we can improve libblkid.
> `blkid` is not able to identify it, but `mount -t fs ...` is able to work.
> the complaint is that `mount -t auto ...` (the default behavior) should have
> mounted it as well.
is it good idea to silently mount corrupted filesystem? The current
behavior is a way how to force users to think about the problem :-)
> looking through the code, the logic for parsing /etc/filesystems and
> /proc/filesystems is that if the probe code was consulted and did not find a
> match for the fs in question, a mount operation is not even attempted. see
> was_tested() and its call to fsprobe_known_fstype(). considering the brute
> force nature of this code, i dont see the point of consulting fsprobe here.
> the "auto" type already asked the probe code to identify the fs and iff that
> fails does mount fall back to the filesystems config files. so it's basically
> asking fsprobe twice for the same answer expecting a different result.
The fsprobe_known_fstype() does not probe anything on the device. I
think that was_tested() is there to identify (for userspace) unknown
filesystems.
> i propose we simply delete that call in was_tested():
> diff --git a/mount/mount.c b/mount/mount.c
> index 0f986df..c9e99ec 100644
> --- a/mount/mount.c
> +++ b/mount/mount.c
> @@ -744,8 +744,6 @@ static int
> was_tested(const char *fstype) {
> struct tried *t;
>
> - if (fsprobe_known_fstype(fstype))
> - return 1;
> for (t = tried; t; t = t->next) {
> if (!strcmp(t->type, fstype))
> return 1;
I see a different problem. The libblkid library checks for ambivalent
probing results -- it means it returns nothing if there is more valid
superblocks on the device to avoid mount(2) for a wrong superblock.
If you remove fsprobe_known_fstype() then you will lost this
functionality in mount(8).
Unfortunately, the current lib/fsprobe.c implementation does not
inform caller about ambivalent probing result (it returns nothing
without any error message). I'll fix it.
My suggestion is use "mount -t <type>" if you know what are you doing
or fix the slightly corrupted filesystem.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
