svn commit: r328013 - head/sbin/fsck_ffs

[Ian Lepore]

On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > 
> > On Fri, Mar 09, 2018 at 09:36:25PM -0500, David Bright wrote:
> > > 
> > > On Mar 9, 2018, at 17:31, Ian Lepore <ian at freebsd.org> wrote:
> > > > 
> > > > 
> > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote:
> > > > > 
> > > > > 
> > > > > etc/rc.d/fsck doesn't know how to interpret the new exit code and now
> > > > > just drops to a single-user shell when it is encountered. [?]
> > > > > 
> > > > > Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to
> > > This is, in fact, the reason that I made the change I did. I was trying to put in a retry loop to rc.d/fsck, but found that I couldn?t get it to work because fsck and fsck_ffs were not exiting with non-zero status. The drop to single user is not really due to the specific (new) error code of 16, it is due to the fact that fsck_ffs is now exiting with a non-zero status when it hasn?t completely cleaned the file system;
> > Sure, but that's a regression IMO: before, I believe we'd successfully
> > mount the FS even without retrying fsck, and continue booting.
> > 
> > > 
> > > /any/ non-zero status would cause the current rc.d/fsck script to go to single user. Prior to my change, fsck_ffs was exiting with a zero status even though it had not completely cleaned the filesystem and told the user to run it again.
> > > 
> > > > 
> > > > 
> > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be
> > > > a better mechanism for handling this new type of retry?
> > > That?s true; however, there is currently no way to pass that flag through the filesystem-agnostic fsck wrapper called from rc.d/fsck to the filesystem-specific fsck_ffs program that it calls. One could implement a similar flag on the fsck wrapper to be passed along to the filesystem-specific checker, but I think fsck_ffs is the only one that currently implements such a flag. 
> > As was pointed out by others, this isn't true. In my experience it's
> > fsck -p that is exiting with status 16. It thus seems like it would be
> > desirable to add "-T ffs:-R" to the initial fsck invocation in
> > rc.d/fsck.
> Please do not do that, if fsck -p fails YOU may optionally
> wish to continue, or do retries, but please do not make this
> a hardcoded situation.  At most make it a controllable knob
> that defaults to the old behavior please.
> 
> Thanks you,

This whole situation with fsck retries is just very strange.  How many
other tools in the base system exhibit this behavior: 

    I didn't do everything you asked, even though I am completely
    capable of doing so.  If you'd like to actually do the thing you
    asked for, please run this program again.

If there is some reason why fsck should do less than a complete job
under some circumstances, isn't THAT the exceptional situation that
should need a special flag to make it happen?

-- Ian