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

[Jin Guojun[VFF]]

On 04/21/20 14:55, Kevin P. Neal wrote:
> On Tue, Apr 21, 2020 at 06:24:26PM +0200, Polytropon wrote:
>> 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.
> Is it useful to have an fstab option that means "fsck MUST succeed! But
> mount doesn't have to."?? Personally, I'm not seeing it. If I had noticed
> "failok" myself I might have assumed it also applied to fsck.
>
> Ok, the man page does say it is processed by "mount" and doesn't mention
> any other program. But I don't see how it makes sense to have an option
> that allows a broken system to come up but only if the brokenness is caught
> by mount and not fsck.
Agreed with failok option for mount should also apply to fsck.

Also, in a sequential operations for the same type of device, the 
falling into the single user mode
should happen in the last step; in this case, the mount daemon. Since 
mount daemon can determine what
file systems it needs, it guides boot-up process for the system, thus no 
reason for fsck to kill the boot process earlier.

If fsck sees a failure, and drops system into single user mode, then 
failok option in fstab is unlikely useful.

For below file system, the /scratch partition is not required. System 
will run well even if it is missing.
User or admin can replace the failure drive later, then, why let system 
down till this problem fixed?

/dev/ada1s1a    /                    ufs     rw       1       1
/dev/ada1s1b    none            swap    sw      0       0
...
/dev/ada0s4d    /scratch         ufs     rw,failok      2       2