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
Hi,
On Wed, 13 Oct 1999 02:19:19 +0400, Hans Reiser [EMAIL PROTECTED] said:
I merely hypothesize that the maximum value of required
FLUSHTIME_NON_EXPANDING will usually be less than 1% of memory, and
therefor won't have an impact. It is not like keeping 1% of memory
around for use by text
-Original Message-
From: Stephen C. Tweedie [mailto:[EMAIL PROTECTED]]
On Wed, 13 Oct 1999 09:55:39 -0400, Chris Mason
[EMAIL PROTECTED] said:
All true. But shouldn't I be able to write function to reuse a
buffer_head
for a different block without freeing it? I realize the
"Stephen C. Tweedie" wrote:
Hi,
On Wed, 13 Oct 1999 02:19:19 +0400, Hans Reiser [EMAIL PROTECTED] said:
I merely hypothesize that the maximum value of required
FLUSHTIME_NON_EXPANDING will usually be less than 1% of memory, and
therefor won't have an impact. It is not like keeping 1%
Hi,
On Thu, 14 Oct 1999 14:31:23 +0400, Hans Reiser [EMAIL PROTECTED] said:
Ah, I see, the problem is that when you batch the commits they can be
truly huge, and they all have to commit for any of them to commit, and
none of them can be flushed until they all commit, is that it?
Exactly.
On Wed, 13 Oct 1999, Jeff Garzik wrote:
Some on linux-kernel mentioned that procfs needed cleanup. Is there a
TODO list somewhere?
Even an initial variant of patch (ouch... porting the thing from
2.3.13-pre1 to 2.3.22-pre2 _did_ hurt; damn CVS...).
I can't promise that in the current
