From: "Stephen C. Tweedie" [EMAIL PROTECTED]
Date: Mon, 11 Oct 1999 17:34:36 +0100 (BST)
The _fast_ quick fix is to maintain a per-inode list of dirty buffers
and to invalidate that list when we do a delete. This works for
directories if we only support truncate back to zero
On 11 Oct 1999 17:58:54 -0500, [EMAIL PROTECTED] (Eric W. Biederman) said:
Ultimately we really want to have indirect blocks, and the directory
in the page cache as it should result in more uniform code, and
faster partial truncates (as well as faster syncs).
Stephen C. Tweedie [EMAIL
Hi,
On Sat, 9 Oct 1999 23:53:01 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] 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
Hi,
On 11 Oct 1999 17:58:54 -0500, [EMAIL PROTECTED] (Eric W. Biederman)
said:
What about adding to the end of ext2_alloc_block:
bh = get_hash_table(inode-i_dev, result, inode-i_sb-s_blocksize);
/* something is playing with our fresh block, make them stop. ;-) */
if (bh) {
if
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
On 11 Oct 1999, Eric W. Biederman wrote:
What about adding to the end of ext2_alloc_block:
It's _equally_ slow. Do you seen my patch? I prefer to do the query at the
higher lever to save cpu cache.
Andrea
Hi,
On Tue, 12 Oct 1999 15:39:35 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] 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
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
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. :)
It's not obvious that the only thing to consider are
G'day!
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
...
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.
Andrea's right in that the semantics make it far too
"Stephen C. Tweedie" [EMAIL PROTECTED] writes:
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will
On Mon, 11 Oct 1999, Stephen C. Tweedie wrote:
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will contain only metadata. Less elements means faster lookups.
On Sat, 9 Oct 1999, Andrea Arcangeli wrote:
On Fri, 8 Oct 1999, Mikulas Patocka wrote:
Here goes quick'n'dirty patch. It does bforget(). It should prevent file
corruption.
wrong patch. bforget give you no guarantee at all. bfoget always fallback
to brelse if necessary.
What I said
On Fri, 8 Oct 1999, Mikulas Patocka wrote:
Here goes quick'n'dirty patch. It does bforget(). It should prevent file
corruption.
wrong patch. bforget give you no guarantee at all. bfoget always fallback
to brelse if necessary.
What I said about bforget in my old email is still true. The _only_
On Fri, 8 Oct 1999, Alexander Viro wrote:
yep we knew about this problem ... it's not quite an easy hack though.
Putting the directory block cache (and symlink block cache) into the page
cache would be the preferred method - this would also clean up the code
alot i think.
More or
Sheesh... Yes, you are right. It was not a problem with the old buffer
cache, but now... Arrgh. Races in truncate(), film at 11. Pheeewww...
Unless I'm seriously misunderstanding what happens you've just dug out a
race in ext2. It doesn't do bforget() on the data blocks in directories.
If
On Fri, 8 Oct 1999, Ingo Molnar wrote:
On Fri, 8 Oct 1999, Alexander Viro wrote:
Stephen, Ingo, could you look at the stuff above? Methink it means that we
either must separate ext2_truncate() for directories (doing bforget() on
the data blocks) _or_ put the directory blocks into
17 matches
Mail list logo
