lkml.org 
[lkml]   [2009]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.6.29
    On Thu, Mar 26, 2009 at 06:03:15PM -0700, Linus Torvalds wrote:
    >
    > Everybody accepts that if you've written a 20MB file and then call
    > "fsync()" on it, it's going to take a while. But when you've written a 2kB
    > file, and "fsync()" takes 20 seconds, because somebody else is just
    > writing normally, _that_ is a bug. And it is actually almost totally
    > unrelated to the whole 'dirty_limit' thing.

    Yeah, well, it's caused by data=ordered, which is an ext3 unique
    thing; no other filesystem (or operating system) has such a feature.
    I'm beginning to wish we hadn't implemented it. Yeah, it solved a
    security problem (which delayed allocation also solves), but it
    trained application programs to be careless about fsync(), and it's
    caused us so many other problems, including the fsync() and unrelated
    commit latency problems.

    We are where we are, though, and people have been trained to think
    they don't need fsync(), so we're going to have to deal with the
    problem by having these implied fsync for cases like
    replace-via-rename, and in addition to that, some kind of hueristic to
    force out writes early to avoid these huge write latencies. It would
    be good to make it be autotuning it so that filesystems that don't do
    ext3 data=ordered don't have to pay the price of having to force out
    writes so aggressively early (since in some cases if the file
    subsequently is deleted, we might be able to optimize out the write
    altogether --- and that's good for SSD endurance).

    - Ted


    \
     
     \ /
      Last update: 2009-03-27 04:25    [W:4.070 / U:0.576 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site