From owner-svn-src-head@freebsd.org Sat Mar 10 17:54:15 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84061F4C3D0; Sat, 10 Mar 2018 17:54:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A9EEF7D5FE; Sat, 10 Mar 2018 17:54:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id uih8eZXamYxCTuihAeT7N6; Sat, 10 Mar 2018 10:54:12 -0700 X-Authority-Analysis: v=2.3 cv=cav8UELM c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=8nJEP1OIZ-IA:10 a=v2DPQv5-lfwA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=VZMtDPgJqhoKK3BJdpwA:9 a=wPNLvfGTeEIA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id A22F610F6; Sat, 10 Mar 2018 09:54:10 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w2AHsATJ038450; Sat, 10 Mar 2018 09:54:10 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w2AHsA2l038446; Sat, 10 Mar 2018 09:54:10 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201803101754.w2AHsA2l038446@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: rgrimes@freebsd.org, Mark Johnston , David Bright , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs In-Reply-To: Message from Ian Lepore of "Sat, 10 Mar 2018 10:26:42 -0700." <1520702802.84937.126.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 10 Mar 2018 09:54:09 -0800 X-CMAE-Envelope: MS4wfOq7dyTWM4z8DrjMvRDhU5Mxp/n9SuDNoigL+OZRcBJugoCSSRgq4sO3zl81TDttbCMK8ZDKE+t8UQ1AJp2LEnXE6VFQnVPOJcyW/GGxmIxODGGzrKT7 v41hlhy4y2JpazTeOhaMwInd6YyD6WRfkiNyupC4c0TU4unvV6cCsUUcgtrO/3XjdpAvvFaIlaROgtI+4kMRw7vONs4yP/IdueSNmW3RiOhZ8IjF4E5p9Lu0 XqSNe2Ol9f6EM1ztM9X3GwpFA1tgpo66THA72bxHdWL6r4x0kc/UXlSh4k+5TBSDDpeMPsRYrqpypoDfy2ltStugbXz0N6ikUtCi6GpR/31he1+UUrij6SK1 hrn9zFyUMeI38dCR/BHs8LUz43oXSljre4PB3P0y12MVcIqiC9E= X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 17:54:15 -0000 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 FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.