[lkml]   [2012]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 4/4] fat: switch to fsinfo_inode
    On Sat, 2012-04-14 at 19:19 +0900, OGAWA Hirofumi wrote:
    > Artem Bityutskiy <> writes:
    > > From: Artem Bityutskiy <>
    > >
    > > 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
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2012-04-14 12:31    [W:0.024 / U:9.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site