Date: Wed, 22 Apr 2020 00:33:21 +1000 From: Scott <freebsd-lists-5@thismonkey.com> To: Polytropon <freebsd@edvax.de>, freebsd-questions@freebsd.org Subject: Re: Should fsck honour "failok" in fstab as mount does? Message-ID: <20200421143321.GA33168@thismonkey.com> In-Reply-To: <20200421160939.aa2fbd89.freebsd@edvax.de> References: <20200421071319.GA98163@thismonkey.com> <20200421153144.d45a889b.freebsd@edvax.de> <20200421135406.GA74559@thismonkey.com> <20200421160939.aa2fbd89.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 21, 2020 at 04:09:39PM +0200, Polytropon wrote:
> On Tue, 21 Apr 2020 23:54:06 +1000, Scott wrote:
> > On Tue, Apr 21, 2020 at 03:31:44PM +0200, Polytropon wrote:
> > > On Tue, 21 Apr 2020 17:13:20 +1000, Scott wrote:
> > > work. The file /etc/fstab is the filesystem table intended
> > > for use with mount; the fact that fsck uses it is just a nice
> > > side effect, but not its primary use. That's why the options
> > > field is intended for the mount command.
> >
> > True, but that doesn't preclude fsck's use of any hints it may glean from
> > /etc/fstab.
>
> The 6th field of /etc/fstab, the "fsck column", is intnded
> to be used by fsck, as per the manual, but of course this
> does not say anything about "what to do in case of problems".
>
>
>
> > > The effect that the system drops into single-user mode is
> > > also intended. When fsck is invoked - upon filesystem error -
> >
> > Sure, but the point of `failok' is to continue booting even if the so
> > optioned filesystem cannot mount for whatever reason. Unfortunately fsck
> > makes no use of this indication and prevents booting. These two commands,
> > fsck and mount need to work in tandem.
>
> Yes, that is correct. However, it looks like "noauto" is
> basically what you're searching for. During the boot process,
> specific filesystems are gathered from /etc/fstab, and their
> consistency is tested before mounting, afterwards they are
> mounted. Later mounting and manual mounting is possible too,
> even with filesystems specified in /etc/fstab, but with the
> "noauto" mount option - in this case, fsck won't even look
> at them, except mount itself could complain ("so-and-so was
> not properly dismounted").
So you've established that fsck parses the fs_mntops column for advice, which
is great. Why not just make it recognise the `failok' option?
>
> So the consensus seems to be: If you don't want fsck to look
> at a filesystem and maybe stop the boot process, use "noauto".
> If you want it to be mounted later on, do so manually (with
> of of the methods I mentioned, or entirely interactively).
Yes but I DO want fsck to look at the filesystem, but continue if it fails
(for example, if the device does not exist). Just like I DO want mount to
mount the filesystem, but continue if it can't.
>
> > > If you don't want fsck to stumble upon a damaged filesystem,
> > > do not include it in /etc/fstab. You can still use a custom
> > > rc.d-style script or an entry in /etc/rc.local if you wish
> > > to "maybe mount" non-vital or optional filesystems later on.
> >
> > Sure, but why would you want to do it that way? The same could be said when
> > the `failok' option was not available to mount.
>
> Right, this approach does not even require "failok".
>
>
> > Consider the situation where a device specified in /etc/fstab is not present
> > during boot, say a USB stick. You've added the `failok' option to its
> > /etc/fstab entry, declaring that if you can't mount the device, ignore the
> > error and continue. fsck will still drop into single user mode. Does that
> > make sense?
>
> Yes, because the entry in /etc/fstab says the device is _required_
> during the boot process - any non-"noauto" entry is to be checked
> and mounted during system boot. The opposite of "noauto" is "auto",
> and it is the default - meaning, according to the manual: "to be
> automatically mounted at system startup". So any of such entries
> is considered "required for booting".
That's not completely true, because for NFS mounts we have the `bg' option,
which allows the system to continue booting even if it can't be mounted.
i.e.: not all `noauto' filesystems are _required_.
> I think you're expecting "failok" to do something it is not
> intended to do.
>
Not really. I want `failok' to do something it doesn't currently. Where
would be the harm in patching fsck to recognise it?
Given the resistance perhaps I should be pushing for fsck to continue on a
non-existent device (really, how does a missing device fail a consistency
check?). Then mount will presumably fail if the `failok' is not present.
Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200421143321.GA33168>