On Thu, 19 May 2011 17:02:21 +0200, "D. Jansen" said:
> On Thu, May 19, 2011 at 3:43 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> 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?