From owner-svn-src-all@freebsd.org Sat Mar 10 17:32:27 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 8D87AF4AAA8 for ; Sat, 10 Mar 2018 17:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C4517C60E for ; Sat, 10 Mar 2018 17:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id h23so6902673iob.11 for ; Sat, 10 Mar 2018 09:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6FpKmWKB54NmMVxlzjpPfjamloACNJI+bj+HGzvEgs4=; b=zaLc8ThwWLTVZt8FboYScw8S9zVY5rfu4jGYVuLBrK64rFwz9S9mRGfPqhvg6tw++H didOZmRR25Hkl21TWSPQPSJyH6xsGAr+tYG4jRzBzXDC5lYrYTGuCAKOIsLrP+gnqDL+ FyATelfiB1knjCWNxBmSHNhmSTYqO9XC/bDZSsfKwXo4ply1DQ6u5wFq3jQbBeK8otVs 4C/Tg7zaQ27+qQv8FAy8jE2rr5ujppLs1cKZXtMs3VAKmp2CleYYby2ytIPaTrUbxiEk lclmPmFNe1EUTIZk1EAj+9uShoZc3bqErHobrkUNI9AcYbz0iudgFHjxn90DY20bCJ4U uPng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6FpKmWKB54NmMVxlzjpPfjamloACNJI+bj+HGzvEgs4=; b=eG7Mq1iyNKHQvhafChcoVuAJ5eoinOc4HU2GsZFvVjx1AXWjDhRUZcek9HYNiOtIYn FdrKw2W4pQC2J6iU7It83c7svtWwFgowcDSYft/ejSPgXd8HMg/iUQlHx64xYzOnR89J eQCh7JBt8aeHOcWOZWJc5coH+Ihpy9NRzRnI0MlKWQZekLP2dW0/YHQkAbD/uSzhMVAt 7NmM/+tKhGwbKrvoHIqesYjYVtyXvy/huSFKPxcVgBOHLusvY1ZnTNFf0LYdjS+KUx2/ 4rNH2+SLh8jhtKXa10QY8lRQ6w6RcUVNwNnGQEqaB7GTQM927l9ta+dAWTFvYf4fTTsB /Kew== X-Gm-Message-State: AElRT7Gw/63vlaGOBVxWGAiFs/ai7jkCXeZTV9tXlI7iTcouTJBAo3bh 6+pCMZTLbzsCctMXyaEd42Lb7vbUjyRrRi8e4CrXCQ== X-Google-Smtp-Source: AG47ELsi0zdudY68rIV/Aub3mfm56C56c+nzLXS1egSQ8YzNGXHMyxrykfOWxKDeQzrdWBS2TQErOrdebeat8b0SQX4= X-Received: by 10.107.175.77 with SMTP id y74mr3013670ioe.37.1520703146387; Sat, 10 Mar 2018 09:32:26 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Sat, 10 Mar 2018 09:32:25 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <1520702802.84937.126.camel@freebsd.org> References: <201803101702.w2AH2uW6070387@pdx.rh.CN85.dnsmgr.net> <1520702802.84937.126.camel@freebsd.org> From: Warner Losh Date: Sat, 10 Mar 2018 10:32:25 -0700 X-Google-Sender-Auth: 9qam31eKIv1q3FQhI83qAtwcYC8 Message-ID: Subject: Re: svn commit: r328013 - head/sbin/fsck_ffs To: Ian Lepore Cc: "Rodney W. Grimes" , Mark Johnston , David Bright , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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:32:27 -0000 On Sat, Mar 10, 2018 at 10:26 AM, Ian Lepore wrote: > 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? > There are some classes of errors that fsck correct that it must recompute a large amount of state to make sure it is consistent. Rather than doing that, it exits with a message saying to re-run fsck to make sure that there aren't more errors that were hidden by the now-corrected errors from the past pass. > 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. > The man page could use some improvement. Preen mode means 'fix all the stupid inconsistencies that crop up that never result in data loss'. non-preen mode means to do that, and ask if you want to correct other errors that usually don't cause data loss, but might and some modicum of human intelligence is required to tell the two apart. Eg, I usually give up hitting 'y' after a dozen or so times in FSCK unless I have a specific reason to keep going. fsck -y has no such nuance. Warner > 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 > > >