Date: Mon, 28 Jun 1999 02:01:51 +0200 From: Francois-Rene Rideau <fare@tunes.org> To: der Mouse <mouse@Rodents.Montreal.QC.CA> Cc: Francois-Rene Rideau <fare@tunes.org>, 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: <19990628020151.A6067@ZhengHe.augustin.thierry> In-Reply-To: <199906272333.TAA23042@Twig.Rodents.Montreal.QC.CA>; from der Mouse on Sun, Jun 27, 1999 at 07:33:32PM -0400 References: <199906272333.TAA23042@Twig.Rodents.Montreal.QC.CA>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 27, 1999 at 07:33:32PM -0400, der Mouse wrote: >> If you re-read the original message, the problem is what to do about >> processes with open file descriptors on the partition [...] > Yes, that's the most difficult part. [...] NetBSD manpage: > -f The filesystem is forcibly unmounted. Active special devices > continue to work, but all other files return errors if further > accesses are attempted. I think that returning errors is WRONG, unless specifically requested by fnctl(). It means that processes will get unexpected errors from otherwise validly open filedescriptor. It means that you can't fix the problem with the filesystem and resume operations nicely afterwards; or you will have to manually stop processes from userland before unmounting, which would not be atomic and generate yet another race condition. Robert seemed to favor atomically stopping processes. I am personally in favor of defaulting to a blocking behavior. >> How will you allow for such large table-walking to be compatible with >> real-time kernel response? > *What* large table-walking? All this means you have to do is have > every write check the relevant mount point to see if it's mounted > read-only, for downgrading remounts, and mark the filesystem as gone, > for forced unmounts. (I suspect this is what deadfs is for.) That's typical incremental behavior. Again, it's a matter of tradeoff: do you want a big atomic operation once in a while and simple operations every time, or complex incremental operations every time? It's real-time response vs overall-time duration. See GC for a field of CS where this trade-off has been beaten to death. Also, the worry was most important in the case of atomically stopping processes as recommended by Robert. Hum. It looks like the need to avoid losing file descriptor information and pending I/O requests would make it a good idea that there be a mount mode without either read or write permissions, similarly to opening files without read or write permissions. Looks to me like an interesting alternative to deadfs, anyway... >> Competition is _not_ about taunting each other for pride; > I know this. I even think most of the people involved know it. Cool. > But there seem to be a few - not many, but very poisonous - who seem to > take any competition - indeed, almost any *difference* - as an > opportunity for "we're better than you" egoboo. "Hey, stupid, my underwear is nicer than yours!" Hum. Let's just send those kiddies to /dev/null; uh, I mean, er, whatever. [ "Faré" | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ] [ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ] [ Reflection&Cybernethics | Project for a Free Reflective Computing System ] My opinions may have changed, but not the fact that I am right. 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?19990628020151.A6067>