Re: reiserfs being part of the kernel: it's not just the code

From: Hans Reiser (hans@reiser.to)
Date: Tue Jun 06 2000 - 21:00:40 EST


"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, Jun 06, 2000 at 10:41:37AM -0700, Hans Reiser wrote:
> >
> > There is no need to delay reiserfs integration into 2.4 to accomplish a
> > journaling API in 2.5.
>
> It wasn't a journaling API we were talking about for this. The problem
> is much more central to the VM than that --- basically, the VM currently
> assumes that any existing page can be evicted from memory with very
> little extra work. It just isn't prepared for the situation that you
> have with transactions, where you can't flush any of the existing dirty
> data to disk without first waiting for the transaction to proceed to a
> consistent, checkpointable state.
>
> We've had a lot of trouble in the past even just with ext2 creating too
> many dirty buffers. That gets a lot worse if you have multiple
> transactional filesystems in memory. It's not the journaling itself, but
> the transactional requirements which are the problem --- basically the
> VM cannot do _anything_ about individual pages which are pinned by a
> transaction, but rather we need a way to trigger a filesystem flush,
> AND to prevent more dirtying of pages by the filesystem (these are two
> distinct problems), or we just lock up under load on lower memory
> boxes.
>
> A reservation API which lets all transactional filesystems reserve
> the right to dirty a certain number of pages in advance of actually
> needing them is really needed to avoid such lockups. The reservation
> call can stall if the memory limit has been reached, providing flow
> control to the filesystem; and a notification list can start committing
> and flushing older transactions when that happens.
>
> Cheers,
> Stephen

We all agree about this. All we disagree about is whether ReiserFS should wait
for it.

Do I miss a finepoint, or can this reservation API be as simple as using an
agreed on counter for total system pinned pages which is constrained to some
percentage of memory? I think we all discussed all of this last year, and the
workshop Riel tried to organize sadly never happened. Perhaps we should do a
workshop July 5 at the Libre Software conference in France? Probably this issue
will already be solved by then, but there are plenty of other discussions to
have in the vicinity of this problem. Actually, I suspect that if one of us
just takes an afternoon and does a patch we'll all just use it, I don't think
this is an area of disagreement.

Hans

-
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/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:27 EST