JLS2009: A Btrfs update
Posted Nov 5, 2009 14:09 UTC (Thu) by nye (guest, #51576)
Nevertheless, it's generally a requirement for consistency in the face of application crashes (never mind system crashes or power cuts), unless you want to be dealing with full-blown transactional operations at the application level - which could be very little work if performed using facilities provided by the filesystem, but then wouldn't be portable.
Posted Nov 5, 2009 14:14 UTC (Thu) by anton (subscriber, #25547)
Of course, for applications that overwrite stuff in place (e.g.,
usually data bases) it's not a good file system, and these applications need fsync() with it.
Posted Nov 8, 2009 2:36 UTC (Sun) by butlerm (guest, #13312)
Most importantly a high performance filesystem needs to be able to sync the
data of one file independent of all the pending data for every other open
file. That is the whole problem with ext3 - it doesn't do that, so an fsync
under competing write load is very slow.
Ext4 fixes these problems, but either requires an fsync or inserts one to
make a rename replacement an atomic operation. That delay could be avoided
with some reasonable internal modifications (keeping the old inode around
until the new inode's data commits, and then undoing the rename if necessary
on journal recovery), but I am not aware of any filesystem that actually does
that. You have to call fsync to make your code portable anyway, but there
are a number of applications where that is too expensive.
Posted Nov 8, 2009 22:04 UTC (Sun) by anton (subscriber, #25547)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds