Re: [patch] [possible race in ext2] Re: how to write get_block?

Stephen C. Tweedie (sct@redhat.com)
Tue, 12 Oct 1999 14:00:13 +0100 (BST)


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/