From owner-freebsd-fs@freebsd.org Wed Nov 28 07:52:31 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 4A84C114B463 for ; Wed, 28 Nov 2018 07:52:31 +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 4B04C85C92 for ; Wed, 28 Nov 2018 07:52:30 +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 wAS7xabP040527; Tue, 27 Nov 2018 23:59:36 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201811280759.wAS7xabP040527@chez.mckusick.com> From: Kirk McKusick To: Rick Macklem Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock cc: Warner Losh , 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 Rick Macklem message dated "Wed, 28 Nov 2018 01:31:23 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40525.1543391976.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Nov 2018 23:59:36 -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: 4B04C85C92 X-Spamd-Result: default: False [0.43 / 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.46)[-0.457,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)[]; NEURAL_SPAM_SHORT(0.54)[0.545,0]; MX_GOOD(-0.01)[cached: chez.mckusick.com]; RCVD_IN_DNSWL_NONE(0.00)[235.157.36.70.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.53)[-0.527,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 07:52:31 -0000 > From: Rick Macklem > To: Warner Losh , Kirk McKusick > CC: Konstantin Belousov , > FreeBSD FS , > "Julian H. Stacey" , > "soralx@cydem.org" > Subject: Re: [bug] fsck refuses to repair damaged UFS using backup super= block > Date: Wed, 28 Nov 2018 01:31:23 +0000 > = > Kirk McKusick wrote: >> >> 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? > = > Is there a concern that a read-only mount of a corrupted non-root > fs could cause the system to panic/crash? > = > For booting, I think Warner is correct to suggest "print a warning > and soldier on..". However, once the system has booted (maybe only > single user), I'd think it would be better to fail the mount at > least until an fsck is done on it than allow it to be mounted > read-only, unless there is no risk that doing this mount could cause > a crash/panic. Obviously, just my opinion given that I don't know UFS. > = > rick Since the initial boot does a read-only mount, my proposal will have the effect that the boot will "print a warning and soldier on..". The root filesystem has to be intact enough to be able to read the boot code and one or more kernel and configuration files from it. If it is able to get that far, it will most likely be able to read-only mount it and get /sbin/init and /bin/sh off it to get to a single-user prompt. By setting the FS_NEEDSFSCK flag on the filesystem, a full fsck will be run as part of trying to come up and will fail to single user if the fsck is not successful. Kirk McKusick