svn commit: r328013 - head/sbin/fsck_ffs

[Cy Schubert]

In message <1520702802.84937.126.camel at 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 at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.