linux-kernel - Re: Linux 2.6.29

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090327034705.GA16888@srcf.ucam.org>
Date:	Fri, 27 Mar 2009 03:47:05 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Theodore Tso <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 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@...f.ucam.org
--
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/