Date: Tue, 15 May 2001 14:17:16 -0400 (EDT) From: mi@aldan.algebra.com To: dillon@earth.backplane.com Cc: jkh@osd.bsdi.com, kris@obsecurity.org, grog@lemis.com, tlambert@primenet.com, mckusick@mckusick.com, ru@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: background fsck and rebooting Message-ID: <200105151817.f4FIHHr26893@misha.privatelabs.com> In-Reply-To: <200105151709.f4FH9XB53717@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[cvs lists taken off the CC] After a second thought, Terry's note, that the reboot IS necessary to ensure, that some files read from the damaged file-system are not corrupted (even if the background fsck succeeds), does not make that much sense to me: . there is an obvious race between those files being read and the reboot time; . as someone else pointed out, we can not restart (or even alert) non-local consumers of the corrupted data (clients) anyway. The above two reasons, IMHO, indicate, that the background fsck should NOT be on by default. Enabling it should be a mount option, and the potential for the troubles should be well documented. Now, to speed up startups, may be, we can mount the filesystems immediately, but hang all read/write attempts until the background fsck is over? This will let programs start, but not run until their data is ready. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105151817.f4FIHHr26893>