lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: msync() behaviour broken for MS_ASYNC, revert patch?
    Linus Torvalds wrote:
    >
    > On Sat, 11 Feb 2006, Nick Piggin wrote:
    >
    >>>Your pattern would actually be
    >>>
    >>> .. dirty offset 100-200 ..
    >>> fadvice(fd, 100, 200, FADV_WRITE_START);
    >>>
    >>> .. dirty offset 200-300 ..
    >>> fadvice(fd, 200, 300, FADV_WRITE_START);
    >>>
    >>> .. dirty offset 300-400 ..
    >>> fadvice(fd, 300, 400, FADV_WRITE_START);
    >>>
    >>> .. dirty offset 400-415 .. (for the next transaction)
    >>>
    >>
    >>- IOW if the app or OS crashed here it would be possible to see 400-415 on
    >>the disk and none of the previous transactions (assuming we don't know
    >>the page size).
    >
    >
    > If the app/OS crashed here, nothing would matter. We haven't committed
    > anything at all yet. We've just started the IO. What is at 400-415 simply
    > doesn't matter, because nobody would have any reason to look at it.
    >
    > (Besides, it's not at all clear that 400-415 would or would not be on
    > disk. It depends on entirely on timing and buffering of the IO system at
    > that point - the fact that its dirty in memory doesn't mean that it ever
    > made it into the IO buffer that was started).
    >
    >
    >>> fadvice(fd, 100, 400, FADV_JUST_WAIT); (for the previous one)
    >
    >
    > This is the one that waits for it to finish, so _now_ we can update the
    > pointers (elsewhere) to that log (and if the app/OS crashes before that,
    > nobody will even know about it).
    >
    > See?
    >

    Well in that case in your argument your FADV_WRITE_START is of
    the "waits for writeout then starts writeout if dirty" type.

    In which case you've just made 3 consecutive write+wait cycles
    to the same page, so it is hardly an optimal IO pattern.

    >
    >>I'm not convinced. You above example was bogus.
    >
    >
    > No, your understanding was incomplete. I'm talking about just parts of a
    > much bigger transaction.
    >
    > A single write on its own is almost never a transaction unless your system
    > is _purely_ log-based (which it could be, of course. Not in my example).
    >

    You were saying that your above sequence would be more efficient
    if implemented with "always start IO, and just wait for IO", because
    "write and wait" would do 2 write+wait cycles.

    However "always start IO, and just wait for IO" does 3 write+wait cycles.

    --
    SUSE Labs, Novell Inc.
    Send instant messages to your online friends http://au.messenger.yahoo.com

    -
    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: 2006-02-10 20:55    [W:4.323 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site