Re: [rfc] Ignore Fsync Calls in Laptop_Mode

From: Valdis . Kletnieks
Date: Fri May 20 2011 - 11:35:33 EST


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

Attachment: pgp00000.pgp
Description: PGP signature