On Monday, November 29, 2010, Ted Ts'o wrote: > By using sync_file_range() first, for all files, this forces the > delayed allocation to be resolved, so all of the block bitmaps, inode > data structures, etc., are updated. Then on the first fdatasync(), > the resulting journal commit updates all of the block bitmaps and all > of the inode table blocks(), and we're done. The subsequent > fdatasync() calls become no-ops --- which the ftrace shell script will > show. Wouldn't it make sense to modify ext4 or even the vfs to do that on close() itself? Most applications expect the file to be on disk after a close anyway and I also don't see a good reason why one should delay a disk write-back after close any longer (well, there are exeption if the application is broken, for example such as ha-logd used by pacemaker, which did for each line of logs an open, seek, write, flush, close sequence..., but at least we have fixed that in -hg now). Cheers, Bernd -- 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
