Re: [PATCH v2 4/4] fat: switch to fsinfo_inode

[OGAWA Hirofumi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/