Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 12 Oct 1999 16:38:50 +0100 (BST) | Subject | Re: [patch] [possible race in ext2] Re: how to write get_block? |
| |
Hi,
On Tue, 12 Oct 1999 15:39:35 +0200 (CEST), Andrea Arcangeli <andrea@suse.de> said:
> On Tue, 12 Oct 1999, Stephen C. Tweedie wrote: >> changes. The ext2 truncate code is really, really careful to provide
> I was _not_ talking about ext2 at all. I was talking about the bforget and > brelse semantics. As bforget fallback to brelse you shouldn't expect > bforget to really destroy the buffer. It may do that but only if it's > possible.
> You are using a _trick_ to let bforget to do the thing you want. If all > filesystem needs such thing it's ugly having to duplicate that current > ext2 tricks all over the place.
Andrea, you are just trying to relax carefully designed buffer cache semantics which are relied upon by the current filesystems. Saying it is a trick doesn't help matters much.
> If you use bforget to avoid fs corruption you are asking for troubles and > IMHO you are going in the wrong direction.
Umm, your last proposal was to do a hash lookup on each new page cache buffer mapping. That is a significant performance cost, which IMHO is not exactly the right direction either. :)
> You may change bforget to do the right thing cleanly, but it will be badly > blocking. While you shouldn't block unless you are the one who wants to > reuse the buffer that is currently under I/O or dirty. So if you'll change > bforget then you'll block in the wrong place.
Unfortunately, the plain fact is that the current page cache relies on data blocks never being in the buffer cache hash lists, and certainly never being dirty in that cache. _That_ is the invariant we need to preserve. truncate already does that for regular files. Please, let's try to keep that clean invariant rather than increase the cost of normal page cache operations.
--Stephen
- 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/
| |