lkml.org 
[lkml]   [2009]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.29
On Thu, Mar 26, 2009 at 11:23:01PM -0400, Theodore Tso wrote:

> Yeah, well, it's caused by data=ordered, which is an ext3 unique
> thing; no other filesystem (or operating system) has such a feature.
> I'm beginning to wish we hadn't implemented it. Yeah, it solved a
> security problem (which delayed allocation also solves), but it
> trained application programs to be careless about fsync(), and it's
> caused us so many other problems, including the fsync() and unrelated
> commit latency problems.

Oh, for the love of a whole range of mythological figures. ext3 didn't
train application programmers that they could be careless about fsync().
It gave them functionality that they wanted, ie the ability to do things
like rename a file over another one with the expectation that these
operations would actually occur in the same order that they were
generated. More to the point, it let them do this *without* having to
call fsync(), resulting in a significant improvement in filesystem
usability.

I'm utterly and screamingly bored of this "Blame userspace" attitude.
The simple fact of the matter is that ext4 was designed without paying
any attention to how the majority of applications behave. fsync() isn't
the interface people want. ext3 demonstrated that a filesystem could be
written that made life easier for application authors. Why on earth
would anyone think that taking a step back by requiring fsync() in a
wider range of circumstances was a good idea?
--
Matthew Garrett | mjg59@srcf.ucam.org

\
 
 \ /
  Last update: 2009-03-27 04:49    [from the cache]
©2003-2011 Jasper Spaans