Is ext4 unsafe?
Thursday, March 19th, 2009 | english
There has been a lot of hype about ext4 lately, following an Ubuntu bug which rose a lot of concerns about ext4 security. I know these are no news, and I know also that I am not a kernel guru, but let’s resume some important concepts.
Ext4 implements something called allocate-on-flush. This means that kernel will decide how to write to disk in an efficient way by batching allocations together in larger runs. It increases performance and reduces fragmentation. But if a system crash happens between metadata and data is actually written to disk a 0-size length file can be found in the filesystem. With ext3 journal had a default timeout of 5 seconds and then was flushed to disk. With ext4 this time is unknown, so appplications that want to ensure everything is on disk have to call fsync() on file and directory after every operation. To avoid this, a series of patches have been queued for 2.6.30 so when a file is going to be replaced, it is written to disk with no delay.
Another concern raised is the need for atomicity and durability of files. For achieving this applications have first to write a temporary file and then rename() it over the old file. This will ensure that new or old file will be found in the filesystem after a crash, instead of a corrupted file that can be found when it is opened with O_TRUNC.
Anyway, my opinion is that when choosing a filesystem, one have to know what the computer is going to be used for. Using binary propietary drivers is an option, which can lead your Linux installation to behave most like Vista and filesystem cannot be blamed for losing files if it is making its job as designed. Perhaps, it’s better to use ext3 in this situation, but at the cost of missing performance.
If you want to learn more about this issues I recommend you to read both articles by Theodore Tso, “Delayed allocation and the zero-length file problem” and “Don’t fear the fsync!” and also AlessanderAlexander Larsson’s one “ext4 vs fsync, my take” as well as comment in all of them.
1 Comment to Is ext4 unsafe?
if you dont care about the state of the filesystem after a crash/power outage, why use a filesystem with journalling, and why bother having fsck installed?
but what if you want to update a file every few minutes/seconds, (history file in a browser, prefs file etc). you dont want to actually write to disk straight away (for performance, powersaving, and ssd lifetime). in the event of a system crash i dont mind if i loose the last half hour of updates to those files, but i will cry if the files are completely deleted.
open(foo.new)
write(foo.new)
close(foo.new)
rename(foo.new, foo)
seems a good way of expressing it. all it demands from the file system is that the rename happens after the actual write of foo.new.
ext4 is currently ruining peoples days because it delays the data write (a good thing), but very quick writes the rename.
the patches makes the data write very quick, so you loose all the advantages of delaying the write.
another solution would be to delay the rename until after the data hits the disk.
another solution, might be to remember the blocks on which the old data was. in the event of a crash the filename could be pointed back to the old data.
Categories
Archive
Meta
Search
March 20, 2009