On Wed, Jan 20, 2016 at 03:00:28PM -0500, Mike Frysinger wrote:
> On 20 Jan 2016 11:28, Karel Zak wrote:
> > On Tue, Jan 19, 2016 at 06:24:58PM -0500, Mike Frysinger wrote:
> > > i've received two requests for the "nofail" option. the doc for the
> > > option is a bit ... terse ... so it's hard to guess at the overall
> > > intention.
> >
> > man mount:
> > nofail Do not report errors for this device if it does not exist.
> >
> > from my point of view this description is pretty explicit :-)
>
> does it mean the device node doesn't exist (ENOENT) ? or does it also
> accept the node being there, but returning other errors like ENXIO (the
> driver isn't loaded) or ENOTDIR (bad path) or ENOTBLK (used a bad path
> like /dev/zero) or ENOMEDIUM (the node & hardware exists, but is not
> loaded) ? there's probably other errno values you could catch here.
>
> surely you agree that "does not exist" does not cover all these cases.
> or at the very least, it's pretty ambiguous/fuzzy.
now we use "nofail" if:
- impossible to translate UUID/LABEL/etc to device name
- mount(2) returns ENOENT and stat() on source fails
- mount(2) returns ENOTDIR and stat() on source fails with ENOTDIR
- mount(2) returns ENOTBLK
- mount(2) returns ENXIO
- and ENOMEDIUM now
... well, maybe we can improve the description in the man page to make
it more user friendly.
> > > (2) ignore unknown fs types. e.g. when a kernel config/module is missing
> > > support for the requested filesystem type. so a fstab entry like:
> > > ..src.. /mnt/foo somefs defaults,nofail
> > > rather than error out with:
> > > mount: unknown filesystem type 'somefs'
> > > it would just issue a warning like it does for other nofail options.
> >
> > I'm not sure with this. It's unusual situation when any filesystem is unknown
> > for libblkid, but it's pretty common that kernel returns EINVAL. This
> > happen when a kernel config/module is missing, but also if you specify
> > wrong mount options and in some another situations. I don't think we
> > want to hide such problems. It's too generic...
>
> i think there's a lot going on in this response. let me distill it a
> bit. if i have a reiserfs that is usable, but i forgot to enable or
> load the reiserfs kernel driver, should nofail be allowed to skip ?
> or is this a hard failure ?
Now it's hard failure and I'm fine with it ;)
In this case kernel returns EINVAL -- the problem is that kernel uses
EINVAL it in another situations too. It makes "nofail" very
problematic for this use-case, because we're not able to detect that
you have no reiserfs driver.
Frankly, people will ask for "nofail" extension all time...
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
