[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: statfs() / statvfs() syscall ballsup...

    On Fri, 10 Oct 2003, Joel Becker wrote:
    > I know that, I agree with it, and I said as much a few emails
    > past. Linux should refuse to corrupt your data. But you've taken the
    > tack "It is unsafe today, so we should abandon it altogether, never mind
    > fixing it.", which doesn't logically follow.

    No, we've fixed it, the problem is that it ends up being a lot of extra
    complexity that isn't obvious when just initially looking at it. For
    example, just the IO scheduler ended up having serious problems with
    overlapping IO requests. That's in addition to all the issues with
    out-of-sync ordering etc that could cause direct_io reads to bypass
    regular writes and read stuff off the disk that was a potential security

    So right now we have extra code and extra complexity (which implies not
    only potential for more bugs, but there are performance worries etc that
    can impact even users that don't need it).

    And these are fundamental problems to DIRECT_IO. Which means that likely
    at some point we will _have_ to actually implement DIRECT_IO entirely
    through the page cache to make sure that it's safe. So my bet is that
    eventually we'll make DIRECT_IO just be an awkward way to do page cache

    And maybe it works out ok. And we'll clearly have to keep it working. The
    issue is whether there are better interfaces. And I think there are bound
    to be.


    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: 2009-11-18 23:46    [W:0.021 / U:0.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site