From owner-freebsd-fs@freebsd.org Sun Nov 25 18:34:45 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 C82C3113CF28 for ; Sun, 25 Nov 2018 18:34:45 +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 8202F71986 for ; Sun, 25 Nov 2018 18:34:44 +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 wAPIgEpW053136; Sun, 25 Nov 2018 10:42:14 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201811251842.wAPIgEpW053136@chez.mckusick.com> From: Kirk McKusick To: Rick Macklem Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock cc: "soralx@cydem.org" , "freebsd-fs@freebsd.org" , "Julian H. Stacey" , Konstantin Belousov X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Rick Macklem message dated "Sun, 25 Nov 2018 15:25:21 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53134.1543171334.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Nov 2018 10:42:14 -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: 8202F71986 X-Spamd-Result: default: False [-0.26 / 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.18)[-0.183,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mckusick.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: chez.mckusick.com]; NEURAL_HAM_SHORT(-0.90)[-0.902,0]; RCVD_IN_DNSWL_NONE(0.00)[235.157.36.70.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.05)[-0.047,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: Sun, 25 Nov 2018 18:34:46 -0000 > 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 super= block > Date: Sun, 25 Nov 2018 15:25:21 +0000 > = >> Kirk McKusick wrote: >> = >> Below is a proposed fix for fsck_ffs to properly handle superblock >> check-hash failures (notably to optionally search for a usable >> alternate superblock). Let me know if you still have a filesystem >> on which you can test it, and if so whether it works correctly. > = > As above, I think you can reproduce this by running an older kernel > that mounts the file system. I ended up re-installing when I ran > into this yesterday (no biggy, it was just a test machine). It > happened after I had been running a kernel built from stable/12 on > the system and then tried to boot it. (Since the root fs got these > errors, I couldn't boot any kernel on the root fs.) Kernels before -r339671 clear the CK_SUPERBLOCK flag in the superblock. = Kernels at and after -r339671 ignore the check-hash if the CK_SUPERBLOCK flag is clear. So you should be able to run on older kernels without causing superblock check-hash failures on later kernels. Fsck will offer to enable the superblock check-hash if you are running on a kernel at or newer than -r339671. > 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 I have fixed the problem with fsck being unable to check filesystems with check-hash failures in -r340925. 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