Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: [PATCH v2 4/4] fat: switch to fsinfo_inode | Date | Sat, 14 Apr 2012 19:36:12 +0900 |
| |
Artem Bityutskiy <dedekind1@gmail.com> 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@mail.parknet.co.jp>
| |