Date: Sat, 10 Mar 2018 10:32:25 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Mark Johnston <markj@freebsd.org>, David Bright <dab@freebsd.org>, src-committers <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: <CANCZdfrJS9nCjqxPOLU%2Bq5Q1BzWf8EYoJgmUjNk1wxXWmPpAHg@mail.gmail.com> In-Reply-To: <1520702802.84937.126.camel@freebsd.org> References: <201803101702.w2AH2uW6070387@pdx.rh.CN85.dnsmgr.net> <1520702802.84937.126.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 10, 2018 at 10:26 AM, Ian Lepore <ian@freebsd.org> wrote: > On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > > > [...] > > > > > 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". > > > > I'm not sure why you think the -R flag is some sort of "ruin my data" > request. Maybe because all of this stuff is so scantily documented in > the manpage? > > -R Instruct fsck_ffs to restart itself if it encounters certain > errors that warrant another run. > > Who knows what "certain errors" means? > There are some classes of errors that fsck correct that it must recompute a large amount of state to make sure it is consistent. Rather than doing that, it exits with a message saying to re-run fsck to make sure that there aren't more errors that were hidden by the now-corrected errors from the past pass. > Looking at the code, it appears -R has no effect if you're in preen > mode. Hmmm, what's "preen mode" again? Don't bother looking in the > man page, you'll just find a bunch of mentions of the word preen that > say "see the -p flag" and then, surrealistically, when you look at the > -p flag it says "Preen file systems (see above)". Of course, what was > above was all the places that told you to see -p. > The man page could use some improvement. Preen mode means 'fix all the stupid inconsistencies that crop up that never result in data loss'. non-preen mode means to do that, and ask if you want to correct other errors that usually don't cause data loss, but might and some modicum of human intelligence is required to tell the two apart. Eg, I usually give up hitting 'y' after a dozen or so times in FSCK unless I have a specific reason to keep going. fsck -y has no such nuance. Warner > So, I guess I'll just keep using fsck_y_enable=YES and relying on the > fact that by default that now includes the -R option. > > -- Ian > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrJS9nCjqxPOLU%2Bq5Q1BzWf8EYoJgmUjNk1wxXWmPpAHg>