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

[Polytropon]

On Wed, 22 Apr 2020 01:58:12 +1000, Scott wrote:
> 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.

Erm, I think the key here is that, as I said, NFS filesystems
won't be checked with fsck, and "bg" will retult the boot
process to continue, no matter if the NFS filesystem can
be mounted at this point (or later on). So yes, for NFS
filesystems the absence of "noauto", especially in presence
of "bg", will not cause a boot process interruption, but in
my opinion, due to the "no fsck needed" reason.



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

The regular way of running fsck here is the "preen mode",
which performs a check for "was dismounted properly", and
can repair minor defects right away. Only if this process
exits != 0, the reasoning is: There is something wrong,
maybe a major filesystem defect, a defective disk, or
something else; let the human decide. :-)



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

In the fsck source, there are deveral exit codes, such as
return to single user mode, cannot read superblock, and
such; only the exit code == 0 will will state that the
filesystem is clean and doesn't need any further attention.
With /etc/rc.d/fsck getting a new condition to decide on,
it could act upon the already existing error codes.



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

I didn't check the source for fsck, just the manual for fstab.
But you're entirely right here. :-)



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

Right. The problem with changing a keyword's meaning could
lead to confusion for admins who _expect_ a certain behaviour.
So maybe new optional keywords would be the better way to go.
So existing configurations just won't notice, and new settings
can be added if desired.

Another possibility would be a keyword named "optional",
so when the filesystem exists && is clean && can be mounted,
it will be accessible; if not, errors at any stage will not
interrupt the mount process. It would probably be a good
idea to have /etc/rc.d/fsck output a warning to the system
log file in such a case, so the admin _can_ perform checks
and repair if it should be needed.




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