[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

    On Sat, 2 Sep 2000, Alexander Viro wrote:
    > +
    > + /*
    > + * So truncate in the middle of a hole not on a block boundary will
    > + * allocate a block. BFD. Everything is still consistent, so trying
    > + * to be smart is not worth the trouble.
    > + */

    You don't actually have to be smart.

    There's a really simple way to avoid this: compare the thing you're going
    to zero out against zero before you memset() it to zero. If it was already
    zero, you just unlock the page and release.

    Downside: you have to read the page in, in order to compare. However, this
    turns out to be a non-issue: if there were no blocks on that page (like a
    forward truncate) this ends up generating no IO anyway. If there _were_
    blocks on the page, it's likely that one of them was the one we're going
    to partially clear anyway, so the "prepare_write()" would have had to read
    it in anyway.

    Upside: you don't need to mark it dirty unnecessarily, assuming you just
    extended the file. No extra allocation, and no extra write to disk.

    Comments? Basically the "grab_cache_page()" would be a "read_cache_page()"
    instead with all the wait-on-page etc stuff.


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

     \ /
      Last update: 2005-03-22 12:38    [W:0.021 / U:7.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site