From: Mike Frysinger <vapier@gentoo.org>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: mount nofail: what failures should we allow ?
Date: Wed, 20 Jan 2016 15:00:28 -0500 [thread overview]
Message-ID: <20160120200028.GE14840@vapier.lan> (raw)
In-Reply-To: <20160120102845.olo242uqrfzld6rh@ws.net.home>
[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]
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.
> > (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 ?
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-01-20 20:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 23:24 mount nofail: what failures should we allow ? Mike Frysinger
2016-01-20 10:28 ` Karel Zak
2016-01-20 20:00 ` Mike Frysinger [this message]
2016-01-21 10:18 ` Karel Zak
2016-01-20 20:20 ` [PATCH] mount: allow nofail to silence ENOMEDIUM cases Mike Frysinger
2016-01-21 9:51 ` Karel Zak
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=20160120200028.GE14840@vapier.lan \
--to=vapier@gentoo.org \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.