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

[Scott]

On Tue, Apr 21, 2020 at 05:03:13PM +0200, Polytropon wrote:
> On Wed, 22 Apr 2020 00:33:21 +1000, Scott wrote:
 
> > 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.

Well no, see the next reply.
 
> 
> > 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).

NFS mounts ARE NOT required for boot to complete if the `bg' option is set.  
mount_nfs just forks off and remains so forked unless the mount completes.  
My point is an absence of `noauto' does not mean a filesystem MUST mount or 
the system drops into single user.

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

Yes.  And the `failok' option modifies SUM (2).  I'm not sure I would have 
`nofsck', rather `fsckfailok' such that fsck is run if possible (in 
preparation for a mount) but booting can continue if not.

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

fsck does seem to have an errorlevel (3) for devices it can't stat, so maybe 
this condition could be pushed to /etc/rc.d/fsck.
 
> 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.

That's not entirely accurate: fsck also checks fs_mntops:

	if (!strncmp(&fs->fs_mntops[i], "noauto", 6))
 
> 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.

Agreed.  The terminology should be either `failok' for all failures 
regardless of the program (fstab (5) does mention it is used by both fsck and 
mount), or split into `mountfailok` and `fsckfailok`.

Scott