[lkml]   [2002]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Possible Idea with filesystem buffering.
    Rik van Riel wrote:

    >On Sun, 20 Jan 2002, Shawn Starr wrote:
    >>But why should each filesystem have to have a different method of
    >>buffering/caching? that just doesn't fit the layered model of the
    >>kernel IMHO.
    >I think Hans will give up the idea once he realises the
    >performance implications. ;)

    Rik, what reiser4 does is take a slum (a slum is a contiguous in the
    tree order set of
    dirty buffers), and just before flushing it to disk we squeeze the
    entire slum as far
    to the left as we can, and encrypt any parts of it that we need to
    encrypt, and assign
    block numbers to it.

    Tree balancing normally has a tradeoff between memory copies performed on
    average per insertion, and tightness in packing nodes. Squeezing in
    response to
    memory pressure greatly optimizes the the number of nodes we are packed
    while only performing one memory copy just before flush time for that
    It is MUCH more efficient. Block allocation ala XFS can be much more
    optimal if
    done just before flushing. Encryption just before flushing rather than
    with every
    modification to a file is also much more efficient. Committing
    also have a complex need to be memory pressure driven (complex enough
    that I won't describe it here).

    So, really, memory pressure needs to push a whole set of events in a well
    designed filesystem. Thinking that you can just pick a page and write it
    and write no other pages, all without understanding the optimizations of
    the filesystem you write to, is simplistic.

    Suppose we do what you ask, and always write the page (as well as some
    other pages) to disk. This will result in the filesystem cache as a whole
    receiving more pressure than other caches that only write one page in
    response to pressure. This is unbalanced, leads to some caches having
    shorter average page lifetimes than others, and it is therefor
    suboptimal. Yes?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:15    [W:0.025 / U:4.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site