On Thursday 11 March 2010 08:13:23 Karel Zak wrote:
> 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.
i'll try to get that info
> > `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 :-)
if the errors were serious, it's up to the kernel fs layers to report/error
out. it isnt mount's job to try and (inaccurately) handle this.
> > 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.
ambivalent results means it should be up to the user/kernel to handle things.
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.
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.
-mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
