Date: Mon, 28 Jun 1999 11:38:49 -0700 (PDT) From: Bill Studenmund <wrstuden@nas.nasa.gov> To: Francois-Rene Rideau <fare@tunes.org> Cc: der Mouse <mouse@Rodents.Montreal.QC.CA>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, NetBSD Kernel <tech-kern@netbsd.org>, OpenBSD Kernel <tech@openbsd.org>, Linux Kernel <linux-kernel@vger.rutgers.edu> Subject: Re: Improving the Unix API Message-ID: <Pine.SOL.3.96.990628112726.20465G-100000@marcy.nas.nasa.gov> In-Reply-To: <19990628010446.A5377@ZhengHe.augustin.thierry>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jun 1999, Francois-Rene Rideau wrote: > On Sun, Jun 27, 1999 at 12:58:05PM -0400, der Mouse wrote: > > See NetBSD (and presumably other BSD) "mount -o update,rdonly" and/or > > "umount -f". (Last I tried, the latter didn't work as it should, but > > that's a matter of fixing bugs rather than introducing new features.) > If you re-read the original message, the problem is what to do > about processes with open file descriptors on the partition: > stop them at once? stop them at first file access? > block them instead? kill them? Will you do it atomically? > How will you allow for such large table-walking to be compatible > with real-time kernel response? [Hint: either use incremental > data-structures, or don't be atomic and be interruptible instead.] unmount -f is more intended for oh-sh*t situations. So harshness is ok. The way it's done is that all of the vnodes in that fs's vnode list get either vgone'd or vcleaned (in the -f case). This will have the effect of mapping them to deadfs vnodes, so all future access will either fail or do nothing (close works, read returns an error). There aren't any big table walks. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.96.990628112726.20465G-100000>