On Sat, 2012-04-14 at 19:19 +0900, OGAWA Hirofumi wrote: > Artem Bityutskiy <dedekind1@xxxxxxxxx> writes: > > > From: Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx> > > > > Currently FAT file-system maps the VFS "superblock" abstraction to the FSINFO > > block. The FSINFO block contains non-essential data about the amount of free > > clusters and the next free cluster. FAT file-system can always find out this > > information by scanning the FAT table, but having it in the FSINFO block may > > speed things up sometimes. So FAT file-system relies on the VFS superblock > > write-out services to make sure the FSINFO block is written out to the media > > from time to time. > > > > The whole "superblock write-out" VFS infrastructure is served by the > > 'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and > > writes out all dirty superblock using the '->write_super()' call-back. But the > > problem with this thread is that it wastes power by waking up the system every > > 5 seconds no matter what. So we want to kill it completely and thus, we need to > > make file-systems to stop using the '->write_super' VFS service, and then > > remove it together with the kernel thread. > > > > This patch switches the FAT FSINFO block management from > > '->write_super()'/'->s_dirt' to 'fsinfo_inode'/'->write_inode'. Now, instead of > > setting the 's_dirt' flag, we just mark the special 'fsinfo_inode' inode as > > dirty and let VFS invoke the '->write_inode' call-back when needed, where we > > write-out the FSINFO block. > > > > This patch also makes sure we do not mark the 'fsinfo_inode' inode as dirty if > > we are not FAT32 (FAT16 and FAT12 do not have the FSINFO block) or if we are in > > R/O mode. > > > > As a bonus, we can also remove the '->sync_fs()' and '->write_super()' FAT > > call-back function because they become unneeded. > > 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. -- Best Regards, Artem Bityutskiy
Attachment:
signature.asc
Description: This is a digitally signed message part
