Jan Kara wrote: > On Tue 20-01-09 15:16:48, Joel Becker wrote: > > On Tue, Jan 20, 2009 at 05:05:27PM +0100, Jan Kara wrote: > > > we noted in our testing that ext2 (and it seems some other filesystems as > > > well) don't flush disk's write caches on cases like fsync() or changing > > > DIRSYNC directory. This is my attempt to solve the problem in a generic way > > > by calling a filesystem callback from VFS at appropriate place as Andrew > > > suggested. For ext2 what I did is enough (it just then fills in > > > block_flush_device() as .flush_device callback) and I think it could be > > > fine for other filesystems as well. > > > > The only question I have is why this would be optional. It > > would seem that this would be the preferred default behavior for all > > block filesystems. We have the backing_dev_info and a way to override > > the default if a filesystem needs something special. > > The reason why I've decided for NOP to be the default is that > filesystems doing proper journalling with barriers should not need > this (as the barrier in the transaction commit already does the job > for them). No, that doesn't work. fsync() doesn't always cause a transaction. If there's no inode change, there may not be a transaction. Writing does not always dirty mtime, if it's within mtime granularity. For efficient fdatasync() you _never_ want a transaction if possible, because it forces the disk head to seek between alternating regions of the disk, two seeks per fsync(). So you can't rely on journalling transactions to flush. > Finally, I prefer maintainers of the filesystems themselves to decide > whether their filesystem needs flushing and thus knowingly impose this > performance penalty on them... I say it should flush be default unless a filesystem hooks an alternative strategy. Certainly, it's silly to have the same code duplicated in nearly every filesystem -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
