Should fsck honour "failok" in fstab as mount does?

[Polytropon]

On Wed, 22 Apr 2020 00:33:21 +1000, Scott wrote:
> 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:
> > > > 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?

No, I'm not saying that. I'm referencing the manual for /etc/fstab,
and it states the requirement that a filesystem is to be clean
and mounted in order to perform automatic system startup, no
matter if "failok" is set or not; from that documentation, I'd
say that this option primarily does what you want, except it
just applies to _clean_ filesystems. The boot process is in
the order "first fsck, then mount", and a mount attempt will
not occur for filesystems that fsck cannot repair automatically
due to significant (!) damages.



> > 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.

That is not the purpose of /etc/fstab, I'd think. As per the
manual, there is a certain requirement for filesystems that
do not have the "noauto" option specified.



> > > > 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_.

They are required, it's just that their mount process is sent
to the background and can happen later on. :-)

I think the main difference here is that NFS mounts are not
subject to a previous fsck success. The core problem here is
that local filesystems will be checked before a mount attempt
can happen (and fail).



> > 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?

No harm, it would surely be possible. It would in fact combine
two things (imaginary "nofsck" followed by "failok"). So what
you expect "failok" ("two in one") to is:

	if filesystem does exist:
		perform fsck
		if fsck successful:
			mount filesystem
			if ! mount successful
				do nothing	<--- SUM (2)
		else
			do nothing		<--- SUM (1)
	else
		do nothing

The arrows indicate points where currently the system boot
process would be interrupted in case of an error. Of course
the order is not intuitive here (error branch should come
first).

You're proposing an interesting approach: "optional mount".
This is something /etc/fstab and fsck + mount currently do
not implement.



> 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.

If the "noauto" option is not present, and the device for
the filesystem does not exist, the boot process will be
interrupted - sure, no fsck, no mount. The "failok" option
could be used for the purpose mentioned above.

As fsck will read /etc/fstab, the "failok" option could be
considered, or a new "nofsck" option could be introduced.
Currently it is of no importance for fsck, as only the
device name, the filesystem type, and the 6th column matter.

Don't get me wrong, I'm not against this idea. The question
is just if "failok" should _imply_ a different fsck and
mount behaviour.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...