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

[Artem Bityutskiy <dedekind1@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Sat, 2012-04-14 at 19:19 +0900, OGAWA Hirofumi wrote:
> Artem Bityutskiy <dedekind1@gmail.com> writes:
> 
> > From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> >
> > 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]