linux-kernel - Re: fs: Inode cache scalability V3

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: <20101014000634.GA21905@infradead.org>
Date:	Wed, 13 Oct 2010 20:06:34 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	axboe@...nel.dk
Subject: Re: fs: Inode cache scalability V3

On Thu, Oct 14, 2010 at 10:55:52AM +1100, Dave Chinner wrote:
> > I wonder what's a good workaround for that.  Just flushing out all
> > dirty state of a block device inode on last close would fix, but we'd
> > still have all the dragons hidden underneath until we finally sort
> > out the bdi reference mess.
> 
> Perhaps for the moment make __blkdev_put() move the inode onto the
> dirty lists for the default bdi when it switches them???in the
> mapping? e.g. add a "inode_switch_bdi" helper that is only called in
> this case?

I really hate to sprinkle special cases all over, but given that Linus
decreed he's not going to take larger writeback changes which would be
required to fix this for .37 it'll be hard to avoid this.

Note that it would really be a bdev_inode_switch_bdi - since the move
to using ->s_bdi for all other inodes these hacks aren't required
anymore, it's just the block devices that continue using the bdi
from the mapping that are causing problems.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/