In message <1520702802.84937.126.ca...@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.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
