Date: Mon, 16 Apr 2001 16:53:08 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: Background Fsck Message-ID: <200104162353.QAA55416@beastie.mckusick.com> In-Reply-To: Your message of "Thu, 05 Apr 2001 00:50:27 EDT." <Pine.NEB.3.96L.1010405001328.24669L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Thu, 5 Apr 2001 00:50:27 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Kirk McKusick <mckusick@mckusick.com> cc: arch@freebsd.org Subject: Re: Background Fsck Kirk, Another usability question. Was wondering about the possibility of multiple background fsck's getting started at a time, et al, possibly due to bad behavior by the user. Can the user get shot in the foot in the following situations: 1) They unmount a file system during a background fsck -- not all that unlikely. (Assuming that fsck keeps a file open for use with the sysctl, or possibly eventually vfsop, a non-forcible unmount should get EBUSY, but not sure what a forcible unmount will do). In the event of a normal unmount request, it will fail with EBUSY. In the event of a forcible unmount, a read or sysctl will fail causing the fsck to terminate with an error. 2) They start a second background fsck running at the same time as the first. This would be indeterminate in the same way as running two foreground fsck's on the same filesystem would be indeterminate. This failure senario has not been considered problematic in the past, so is not guarded against. 3) They perform a remount, possibly changing between read-only and read-write. A background fsck will fail on a read-only filesystem. If the filesystem is downgraded to read-only, a background fsck will fail (and exit) on its next sysctl that attempts to write data. At the moment, it is not possible to toggle soft updates with mount options. If this capability were added, seriously bad things could happen if soft updates were disabled while a background fsck was in progress. In some of these, it may be OK for the user to be shot in the foot, but it might be worth considering strategies to prevent foot-shooting, especially in the case of remount situations. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services Only (2) seems to be a problem, and it has not proven to be an issue in years past. If it is perceived to be a bigger problem now, a fix could be found. A general solution would be to flock the underlying special device as this would work for both foreground and background fsck. At the moment, the /dev filesystem cannot handle advisory file locks, so some serious work would be needed there first. If only background fsck is considered to be an issue, then an flock could be held on the mount point directory. This latter approach seems half baked to me, so I am not inclined to do it. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104162353.QAA55416>