Artem Bityutskiy <dedekind1@xxxxxxxxx> writes: >> Hm, does this guarantee to flush FSINFO at umount? > > Of course, and I checked it. It is just a dirty inode. If you do not > worry that any other inode won't get written-beck, then you should not > worry about this one. > >> FSINFO is last part of data dependency. I.e. inode change can dirty >> FSINFO. So, FSINFO has to be flushed after normal inodes. > > Sorry, I do not see how this can be true. You have a just bunch of dirty > inodes, and it does not matter in which order you flush them. See > __fat_write_inode() - it does not change the FAT table and does not > affect the FSINFO block. > > Besides, the _current_ code first writes out FSINFO, because VFS calls > ->sync_fs() first, then it starts writing back, then VFS calls > ->sync_fs() for the second time. Common case is delayed allocation though, in the case of FATfs, it would be only truncate by last iput(). -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
