On Sat, 2012-04-14 at 19:36 +0900, OGAWA Hirofumi wrote: > 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. This is actually not exactly correct, but anyway, the first ->sync_fs(sb, 0) may come to FAT FS while it is in the middle of writing out the inodes. BTW, fat_clusters_flush() does not wait on the FSINFO block, which I think is a bug. I mean, it should call 'sync_dirty_buffer()'. I can submit a separate patch later. > Common case is delayed allocation though, in the case of FATfs, it would > be only truncate by last iput(). Sorry, I do not understand what you mean. Do you still want me to take care of the order or not? If yes, could you please explain why? -- Best Regards, Artem Bityutskiy
Attachment:
signature.asc
Description: This is a digitally signed message part
