Should fsck honour "failok" in fstab as mount does?
freebsd-lists-5 at thismonkey.com
Tue Apr 21 15:58:33 UTC 2020
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)
> do nothing <--- SUM (1)
> 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
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`.
More information about the freebsd-questions