Re: Possible Idea with filesystem buffering.

Josh MacDonald
2002-01-23T17:18:10Z

Quoting Rik van Riel (riel@conectiva.com.br):
> On Tue, 22 Jan 2002, Hans Reiser wrote:
> > Rik van Riel wrote:
> > >On Tue, 22 Jan 2002, Chris Mason wrote:
>
> > >>The FS doesn't know how long a page has been dirty, or how often it
> > >>gets used,
> > >
> > >In an efficient system, the FS will never get to know this, either.
> >
> > I don't understand this statement. If dereferencing a vfs op for
> > every page aging is too expensive, then ask it to age more than one
> > page at a time. Or do I miss your meaning?
>
> Please repeat after me:
>
> "THE FS DOES NOT SEE THE MMU ACCESSED BITS"
>
> Also, if a piece of data is in the page cache, it is accessed
> without calling the filesystem code.
>
>
> This means the filesystem doesn't know how often pages are or
> are not used, hence it cannot make the decisions the VM make.
>
> Or do you want to have your own ReiserVM and ReiserPageCache ?

Rik,

We think there are good reasons for the FS to know when and how
its data is accessed, although this issue is less significant than
the semantics of writepage() being discussed in this thread.

Referring to the transaction design document I posted several months
ago:

http://marc.theaimsgroup.com/?l=linux-kernel&m=100510090926874&w=2

Our intention is for the file system to be capable of tracking
read and write data-dependencies so that it can safely defer
writing batches of data and still guarantee consistent crash
recovery from the application's point of view. The interaction
between transactions and mmaped regions may leave something to
be desired, and we may not need to know how often pages are or
are not used, but we would like to know which pages are read and
written by whom, even for the case of a page cache hit.

-josh

--
PRCS version control system http://sourceforge.net/projects/prcs
Xdelta storage & transport http://sourceforge.net/projects/xdelta
Need a concurrent skip list? http://sourceforge.net/projects/skiplist