Date: Sat, 10 Mar 2018 09:54:09 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> 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: <201803101754.w2AHsA2l038446@slippy.cwsent.com> In-Reply-To: Message from Ian Lepore <ian@freebsd.org> of "Sat, 10 Mar 2018 10:26:42 -0700." <1520702802.84937.126.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <1520702802.84937.126.camel@freebsd.org>, Ian Lepore writes: > 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? > > 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. > > 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. That's how I've set up my firewall/gateway. For it I'm much more concerned to have it successfully boot than data loss. The reason is if I'm remote I want to be able to ssh back in. So, I'm willing to take the risk to be able to do so. Having said that, I maintain backup slices on an alternate disk in case of loss should the primary slice fail to boot. In that case data loss is tolerable to allow a better chance I can remotely ssh in. (Of course there's no 100% guarantee if there's data loss but it's better than 0% if the gateway dropped into single user state from the get-go.) With my other gear using UFS I want a failing fsck to fall to single user as I can get in using a console server to examine the damage decide for myself. Long story short, it depends. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803101754.w2AHsA2l038446>