Tigran Aivazian <tigran@veritas.com> said:
> On Sat, 1 Jul 2000, Horst von Brand wrote:
> > Jamie Lokier <lk@tantalophile.demon.co.uk> said:
[...]
> > > revoke() without killing the process would be quite useful for floppies
> > > removed from the drive...
> > Which presuposes applications capable of handling said event gracefully.
> > I.e., zilch.
> no, incorrect. It doesn't presuppose anything _at all_!
Oh, come on. How many applications do you know which are prepared to handle
the case that the file they were happily rooting around in suddenly isn't
anymore?
> The point of revoking or forcibly umounting is _not_ to satisfy some
> nasty applications (if it were we wouldn't be SIGKILLing them first, see
> fuser -k manpage to see what it does (yes, there is an non-portable
> -signal parameter but probably nobody uses it)). The point is to be able
> to free the underlying resources in a consistent manner, consistent
> filesystem-wise and obviously not necessarily application-wise. The
> kernel can never guarantee application consistency and shouldn't even try
> to.
Disagree. It is the kernel's responsibility to give application consistency
as far as it can. That we can live with the cases where it doesn't work out
is only because (thankfully) they are rather rare.
> Therefore, both BSD-style revoke(2) and Solaris8 style generic forced
> umount will be generally useful and require no assumptions on applications
> side (for a simple reason that "we can't and therefore don't care" ;)
I don't see the use. My processes will get killed (or much worse, will
screw up (badly, remember Murphy?)) when their files dissapear under
them. Sure, being able to kill(2) a process regardless of where it hung
would be nice. But is it really worth the cost?
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST