linux-kernel - Re: [PATCH 2/7] writeback: switch to per-bdi threads for flushing data

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]

Date:	Mon, 16 Mar 2009 11:21:31 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Dave Chinner <david@...morbit.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, npiggin@...e.de
Subject: Re: [PATCH 2/7] writeback: switch to per-bdi threads for flushing
	data

On Mon, Mar 16 2009, Christoph Hellwig wrote:
> On Mon, Mar 16, 2009 at 08:33:21AM +0100, Jens Axboe wrote:
> > This is very useful feedback, thanks Dave. So on the filesystem vs bdi
> > side, XFS could register a bdi per allocation group. Then set the proper
> > inode->mapping->backing_dev_info from sb->s_op->alloc_inode and
> > __mark_inode_dirty() should get the placement right. For private
> > traverse and flush, provide some address_space op to override
> > generic_sync_bdi_inodes().
> > 
> > It sounds like I should move the bdi flushing bits separate from the bdi
> > itself. Embed one in the bdi, but allow outside registration of others.
> > Will fit better with the need for more than one flusher per backing
> > device.
> 
> Yes, having a separate flushing container is a good idea.  Either way
> I'm not sure how much use all this is for XFS.  We're working on using
> our own flushing code as we want to iterate the inodes using the
> knowledge about their placement on disk.  Due to that we don't use
> the dirty inode list anymore (already in mainline since 2.6.29-rc) but
> the per-ag radix-tree.  The finer granularity pdflush management might
> come in handy, but we'll hand off to some XFS-specific code at a pretty
> high level in there.

Nobody says that you have to use the inode lists for iteration. Or
perhaps it would be possible to plug __mark_inode_dirty() and allow for
alternate placement of the inode upfront.

I'll definitely proceed with the flushing container approach. And I'd
very much like to work with XFS to ensure that it caters to that end as
well, makes it a lot more applicable imho.

-- 
Jens Axboe

--
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/