lkml.org 
[lkml]   [2002]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Possible Idea with filesystem buffering.
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:3.151 / U:0.440 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site