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 sta
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
"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
> -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 re
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
Hi,
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 buffer cache
> doesn't have a call to do it now, but it seems like it should be p
Hi,
To follow up on the kernel announce of the ext3-0.0.2 snapshot, there
are a couple of tools available for helping with migrating to/from ext3.
In particular, the current e2fsprogs work-in-progress snapshot at:
http://web.mit.edu/tytso/www/linux/dist/e2fsprogs-1.16-WIP.tar.gz
has support
Hi all,
OK, a couple of weeks later than I'd hoped and massive numbers of
bug-fixes further on, ext3-0.0.2 is out.
This is the first usable release. Apart from the critical failure
handling (handling of IO errors or memory allocation failures), this is
the first solid version of journaled ext
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 -
