From owner-svn-src-all@freebsd.org Sat Mar 10 17:26:52 2018 Return-Path: Delivered-To: svn-src-all@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 C4F21F4A2F3 for ; Sat, 10 Mar 2018 17:26:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48F1B7C007 for ; Sat, 10 Mar 2018 17:26:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 228c21c3-2488-11e8-bb8e-b35b57339d60 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 228c21c3-2488-11e8-bb8e-b35b57339d60; Sat, 10 Mar 2018 17:26:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2AHQgTO011245; Sat, 10 Mar 2018 10:26:42 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1520702802.84937.126.camel@freebsd.org> Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs From: Ian Lepore To: rgrimes@freebsd.org Cc: Mark Johnston , David Bright , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sat, 10 Mar 2018 10:26:42 -0700 In-Reply-To: <201803101702.w2AH2uW6070387@pdx.rh.CN85.dnsmgr.net> References: <201803101702.w2AH2uW6070387@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 17:26:52 -0000 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. -- Ian