[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090402233806.GG9870@mit.edu>
Date: Thu, 2 Apr 2009 19:38:06 -0400
From: Theodore Tso <tytso@....edu>
To: "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>
Cc: Ray Lee <ray-lk@...rabbit.org>, david@...g.hm,
Matthew Garrett <mjg59@...f.ucam.org>,
Sitsofe Wheeler <sitsofe@...oo.com>,
Alberto Gonzalez <info@...bu.es>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Ext4 and the "30 second window of death"
On Thu, Apr 02, 2009 at 10:59:39PM +0200, Andreas T.Auer wrote:
>
> Yes, but a lot of users (and I assume >90% of POP3 users) don't use this
> option.
>
Sometimes, the filesystem isn't the best place to solve all problems.
What's been frustrating about this whole controversy is this implicit
assumptions that users and applications should never change, and the
filesystem should magically accomodate and Do The Right Thing.
If you're *never* going want to risk ever losing mail, then fine,
fsync() it to disk before you send the POP3 DELETE command. If you
don't like the performance delay, or the battery consumption
implications, tough. I'm fresh out of magic pixie dust.
If the application is smarter about not deleting the messages from the
POP spool, then you can afford not to fsync(). But (oh, horrors!) it
might involve making the application smarter, and playing a
synchronization game between the local POP spool and IMAP. It's more
efficient to do this with IMAP, but there are POP clients that do this.
If you are a mail client developer, and the user says, "I want the
advantages of IMAP, but I refuse to switch to an ISP that provides
IMAP; you must give me *all* the advantages IMAP even though I'm using
POP3", you'd probably tell the user, "Yes, and do you want a pony,
too?"
The problem is, this is what the application programmers are telling
the filesystem developers. They refuse to change their programs; and
the features they want are sometimes mutually contradictory, or at
least result in a overconstrained problem --- and then they throw the
whole mess at the filesystem developers' feet and say, "you fix it!"
I'm not saying the filesystems are blameless, but give us a little
slack, guys; we NEED some help from the application developers here.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists