Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 12 Oct 1999 14:00:13 +0100 (BST) | Subject | Re: [patch] [possible race in ext2] Re: how to write get_block? |
| |
Hi,
On Sat, 9 Oct 1999 23:53:01 +0200 (CEST), Andrea Arcangeli <andrea@suse.de> said:
> What I said about bforget in my old email is still true. The _only_ reason > for using bforget instead of brelse is to get buffer performances (that in > 2.3.x are not so interesting as in 2.2.x as in 2.3.x flushpage is just > doing the interesting stuff with the real data).
> The current design bug in 2.3.20pre2 and previous has nothing to do with > bforget.
Nope. We spent a fair amount of effort on this with the page cache changes. The ext2 truncate code is really, really careful to provide bforget() with the correct conditions to get rid of the buffer: it is a closely designed interaction between delete and bforget. Remember, we have exactly the same potential problems when freeing dirty indirect blocks as we have when freeing directory blocks.
There's a big comment near the top of fs/ext2/truncate.c about the way in which this works.
> The right fix is to do a query on the hash every time you overlap a > buffer on the page cache.
Ouch --- that pays the penalty for normal data blocks every time you pull them into cache. No way.
The correct way to extend the current rules cleanly is to make the truncate code do a bforget() on data blocks as well as indirect blocks if, and only if, the file is not a regular file. That will deal with the symlink case too, and will mean that we are using the same mechanism for all of our dynamically-allocatable metadata.
--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/
| |