ext4 and data consistency
Posted May 14, 2010 13:21 UTC (Fri) by anton
In reply to: ext4 and data consistency
Parent article: The Next3 filesystem
There is no file system in Linux that tries to assure
that renames are atomic functions.
That may be true (wrt. what happens on crashes; I do hope that they
are all atomic wrt state visible to other processes in regular
operations); I certainly have never seen any Linux file system give
any guarantees about data consistency on crashes. Not doing renames
properly would be pretty poor of Linux, though, given that this is a
case where even the old BSD FFS goes to extra lengths to ensure at
least meta-data consistency (it never cares about your data).
Concerning Linux file systems, I am pretty sure that ext3 with the
default data=ordered mode can result in an inconsistent data state if
file overwriting is happening, but data consistency would be
achievable for files that are freshly created (I don't know if ext3
actually achieves it, though). For ext4 I don't expect any data
So ya.. apparently that 'fsync' was always needed by
application developers if they wanted to ensure that data was written
to disk in a timely fashion.
Yes, but that's neither necessary nor sufficient for data consistency.
[...] in Ubuntu the dpkg program detects if it's running on
Ext4 and goes into paranoid mode were it runs 'fsync' were as with
Ext3 it does not. This causes Ubuntu installs to last significantly
longer if you choose 'Ext4' file system.
Oh, really? We have dozens of Debian systems running on ext3
(presumably without paranoid mode), and we have not had a single
problem with a dpkg database corrupted by the file system. What does
Ubuntu do with dpkg that makes a significant
the length of the installation life? And where can I find the
statistics on which you base this claim?
to post comments)