On 11/29/10 9:18 AM, Bernd Schubert wrote: > 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 but those applications would be wrong. http://www.flamingspork.com/talks/ Eat My Data: How Everybody Gets File IO Wrong -Eric > 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 -- 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
