Date: Sat, 10 Mar 2018 09:02:56 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Ian Lepore <ian@freebsd.org> Cc: rgrimes@freebsd.org, Mark Johnston <markj@freebsd.org>, David Bright <dab@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs Message-ID: <201803101702.w2AH2uW6070387@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1520700999.84937.119.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@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? The job is "make sure my data is ok, keep my data at all costs, do not however do something that may damange my data". The job is NOT "do everything you can to bring the file system to a consistent state, even if you have to screw my data all up". -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803101702.w2AH2uW6070387>