From owner-freebsd-fs@freebsd.org Wed Nov 28 01:18:44 2018 Return-Path: Delivered-To: freebsd-fs@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 642931142393 for ; Wed, 28 Nov 2018 01:18:44 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 88D4177CB2 for ; Wed, 28 Nov 2018 01:18:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id wAS1PZAG034119; Tue, 27 Nov 2018 17:25:35 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201811280125.wAS1PZAG034119@chez.mckusick.com> From: Kirk McKusick To: Warner Losh Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock cc: Rick Macklem , Konstantin Belousov , FreeBSD FS , "Julian H. Stacey" , "soralx@cydem.org" X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Warner Losh message dated "Sun, 25 Nov 2018 12:01:45 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <34117.1543368335.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Nov 2018 17:25:35 -0800 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Rspamd-Queue-Id: 88D4177CB2 X-Spamd-Result: default: False [-0.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[mckusick@mckusick.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-0.47)[-0.466,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mckusick.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[chez.mckusick.com]; NEURAL_HAM_SHORT(-0.26)[-0.258,0]; RCVD_IN_DNSWL_NONE(0.00)[235.157.36.70.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.54)[-0.537,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:46375, ipnet:70.36.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.02)[country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 01:18:44 -0000 > From: Warner Losh > Date: Sun, 25 Nov 2018 12:01:45 -0700 > Subject: Re: [bug] fsck refuses to repair damaged UFS using backup super= block > To: Kirk McKusick > Cc: Rick Macklem , FreeBSD FS , > "Julian H. Stacey" , > "soralx@cydem.org" > = > On Sun, Nov 25, 2018, 11:35 AM Kirk McKusick = >>> From: Rick Macklem >>> To: "soralx@cydem.org" , >>> Kirk McKusick >>> CC: "freebsd-fs@freebsd.org" , >>> "Julian H. Stacey" >>> >>> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup >> superblock >>> Date: Sun, 25 Nov 2018 15:25:21 +0000 >>> >>> It would be nice if there was a way to override the check and boot >>> the system. (Is a loader tunable reasonable for this?) >>> >>> rick >> >> Rather than adding a loader tunable to override the check (which people >> would have to track down in the midst of a crisis), it might be better >> to simply have the loader print a warning when there is a mismatch and >> proceed to try using the filesystem. If successful, an fsck could then >> be run to try and clean it up. Does this seem reasonable? >> >> Kirk McKusick > = > Yes. You have a big chicken and egg issue otherwise. And not booting > seems like an extreme overreaction to a bad checksum. I can think > of no use case where you'd want it. Let's let people ask for it > with a decent use case before we do anything more than print a > warning and soldier on... > = > Warner My proposal is that when a filesystem is being mounted read-only that superblock check-hash failures should be warnings only. This is true not just at boot time, but always. We should probably set the FS_NEEDSFSCK flag so that if it is updated to read-write a warning will get printed. Since booting always starts up with the filesystem in read-only mode, this should solve the booting problem. Does this seem like a sensible solution? Kirk McKusick