On Monday, November 29, 2010, Eric Sandeen wrote: > 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. Of course they are, I don't deny that. But denying the most applications expect the file to be on disk after a close() also denies reality, in my experience. And IMHO, such temporary files as pointed out by Ted either should go to tmpfs or should be specially flagged as something like O_TMP. Unfortunately, that changes symantics and so indeed the only way left is to do it the other way around as Ted suggested. 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
