[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: (reiserfs) Re: RE: journal requirements for buffer.c (was:
From:       "Stephen C. Tweedie" <sct () redhat ! com>
Date:       1999-10-12 12:00:09
[Download RAW message or body]

Hi,

On Tue, 12 Oct 1999 03:14:03 +0400, Hans Reiser <reiser@idiom.com> said:

>> Hans, you didn't mention a journal call that happens on sync, or
>> sync_old_buffers...

> I see two issues: how to respond to memory pressure, and how to sync.
> I'll let you articulate our sync needs.

There are actually two separate memory pressure concerns.  The first is
how to clear out some dirty, pinned buffers when we need to free up some
memory, and try_to_free_buffers/bdflush are the main mechanisms involved
right now.

With journaling, however, we have a new problem.  We can have large
amounts of dirty data pinned in memory, but we cannot actualy write
that data to disk without first allocating more memory.  I'm not sure
about the reiserfs case, but in ext3 I certainly need to allocate
buffers to describe control blocks in the journal, for example.  

This introduces a second memory pressure requirement: we must always
restrict the amount of unrecoverable dirty pinned memory so that when we
want to reclaim that memory, we have enough unpinned pages left to
complete the commit operation.

This came up in discussions with the XFS people [hence the linux-fsdevel
cross post]: it matters to many filesystems.  In XFS it is a
substantially more significant problem, because they are performing
delayed allocation of written data and so they potentially need a lot
more space in core for metadata updates before the data can be flushed
to disk.

This is much less of a problem for ext3 and will also probably not
matter too much for reiserfs until you decide to move to lazy block
allocation.  However, a common mechanism for dealing with this would
definitely let all three filesystems survive just that bit better under
really serious memory pressure.

--Stephen

[prev in list] [next in list] [prev in thread] [next in thread]