Re: Bug#605009: serious performance regression with ext4

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with ext4"):
> On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o <tytso@mit.edu> wrote:
> > I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
> > would be best.
> 
> Are there any plans to provide an API for atomic (non-durable) file
> updates, not involving fsync?

Yes.  Such an API has already been defined by POSIX, SuSv3, et al.
It's called "rename".

dpkg used it correctly before filesystem bugs (and associated
intransigence by fs maintainers[1]) forced the current dpkg
maintainers to add a whole pile of pointless fsyncs.

dpkg does _not_ need durable updates; it just needs atomicity and
correctness.  If after a crash the system is rewound to some earlier
state that's absolutely fine.

I'm told that the Linux fs maintainers have now accepted that 
   open("file.new",O_CREAT);
   write();
   close();
   rename("file.new","file");
should not result, even after a crash, in "file" containing garbage.

If this is the case then all the fsyncs can be taken out again.

Ian.

[1] The view that fsync is the new IAC DONT RANDOMLY-LOSE.