On Thu, Mar 11, 2010 at 02:59:16PM -0500, Mike Frysinger wrote:
> > 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.
>
> ambivalent results means it should be up to the user/kernel to handle things.
kernel can't handle this problem, mount(2) simply mounts the requested
filesystem if there is a valid superblock on the device.
Yes, user can completely bypass FS detection, but reality is that
many users use "auto" or they use any HAL/udisk/automount/whatever. I
guess these users don't want to lost data.
> we already have a mechanism for specifying preferences between different
> filesystems -- /etc/filesystems. i dont see why we need to encode this policy
> which will never be perfect (by virtue of the system) into the mount utilities
> and related libraries.
I'd like to avoid any policy (=preference between filesystems),
because this solution does not work. The rule is simple -- there
should be only one valid FS on the device (with some exceptions like
CDROMs or FS+RAID). If there is more valid filesystems on the device
then is necessary user's intervention (fix the device or explicitly
define FS type). Something like /etc/filesystems is extremely poor
solution.
> but before we descend into semantics, the behavior imo is clear: if the mount
> code falls back to "auto" mode, it should explicitly try every entry listed in
> /etc/filesystems followed by /proc/filesystems without any sort of "magic"
> filter applied by the blkid/fsprobe layers. this is how it has always worked
> in the past and i see no reason why it should change. blkid/fsprobe are great
> at trying to detect the correct answer up front. if they fail at their job,
> they should not be affecting the brute force stage.
I agree that the brute force stage should not be affected if libblkid
is not able to detect any filesystem (like in your example). I'm going to
fix this problem.
And I'm going to fix mount(8), the problem with ambivalent probing result
should be properly reported to user and user should be informed that the
problem is possible to bypass by "-t <type>" (or wipefs(8)).
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
