linux-kernel - Re: [PATCH v2 4/4] fat: switch to fsinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1334399379.2263.8.camel@koala>
Date:	Sat, 14 Apr 2012 13:29:37 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
	Linux FS Maling List <linux-fsdevel@...r.kernel.org>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
Subject: Re: [PATCH v2 4/4] fat: switch to fsinfo_inode

On Sat, 2012-04-14 at 19:19 +0900, OGAWA Hirofumi wrote:
> Artem Bityutskiy <dedekind1@...il.com> writes:
> 
> > From: Artem Bityutskiy <artem.bityutskiy@...ux.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

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)