[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] Ignore Fsync Calls in Laptop_Mode
    On Thu, 19 May 2011 17:02:21 +0200, "D. Jansen" said:
    > On Thu, May 19, 2011 at 3:43 PM, Alan Cox <> wrote:
    > > That at least cuts down most failures (but not all - eg commits with a network
    > > component such as email receives)
    > I don't understand your email example.

    If you don't understand Alan's example, maybe you shouldn't be messing with
    code that's used for correctness guarantees. But I'll spell it out for you:

    You turn on laptop mode. You check your mail. You download 5 new messages,
    which your laptop then *assures* the mail server "I've got them, we're cool".
    Now, this is a pretty heavy responsibility (for example, RFC2821 says this:

    6.1 Reliable Delivery and Replies by Email

    When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
    message in response to DATA), it is accepting responsibility for
    delivering or relaying the message. It must take this responsibility
    seriously. It MUST NOT lose the message for frivolous reasons, such
    as because the host later crashes or because of a predictable
    resource shortage.

    So - the mail server then deletes the mail because the laptop has told it "Yes,
    I've gotten it, it's stable, and even if I crash I won't lose it". But since
    the mail program's fsync() calls got suppressed, it really *isn't* stable, so
    when you crash, the mails are gone. Poof.

    Second order effects crop up after that - after you recover from the crash,
    your end has no memory of downloading the 5 messages, so it tries again - only
    to have the mail server say "No such message". This is the sort of inconsistency
    that gives guys at the support desk indigestion...

    Understand better now?

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2011-05-20 17:37    [W:0.059 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site