Date: Wed, 28 Nov 2018 22:06:10 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Kirk McKusick <mckusick@mckusick.com> Cc: Rick Macklem <rmacklem@uoguelph.ca>, FreeBSD FS <freebsd-fs@freebsd.org>, "Julian H. Stacey" <jhs@berklix.com>, "soralx@cydem.org" <soralx@cydem.org> Subject: Re: [bug] fsck refuses to repair damaged UFS using backup superblock Message-ID: <20181128212428.H2715@besplex.bde.org> In-Reply-To: <201811280759.wAS7xabP040527@chez.mckusick.com> References: <201811280759.wAS7xabP040527@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Nov 2018, Kirk McKusick wrote: >> From: Rick Macklem <rmacklem@uoguelph.ca> >> ... >> Is there a concern that a read-only mount of a corrupted non-root >> fs could cause the system to panic/crash? >> ... > 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. Allowing read-only mounts of dirty file systems is only good for the root file system (and the file system containing fsck if this is different). It is fairly safe for the root file system since unless the initialization order is wrong, the worst that can happen is a panic that doesn't cause further damage since no file systems are mounted read-write and no networks have been brought up. It is not safe later since panics for the garbage in the dirty file system might damage file systems mounted read-write. If mounting does more sanity checks than just checking the dirty flag. ext2fs has capability flags which control mounting. Some capabilities require special support even for read-only mounts, so if the file system needs such capabilities but the kernel doesn't support them, then even read-only mounts are denied. Supporting read-only mounts of corrupted file systems is a capability that not many kernels have, so a capability flag for this would rarely be set, and you would need a force flag to force the read-only mount, and would use this for the root file system. FreeBSD already has a force flag to force read-write mounts. It is very easy to add the force flag next to the read-only flag in vfs_mountroot.c, and easy to change ffs to make the force flag control read-only mounts. Supporting read-only mounts of dirty file systems would require close to a full fsck on every mount, or better, runtime checks for all metadata every time it is used, and non-fatal error handling when the checks fail. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181128212428.H2715>