linux-kernel - Re: [PATCH 1/7] writeback: move dirty inodes from super_block to backing_dev

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] [day] [month] [year] [list]

Message-ID: <20090324184548.GY27476@kernel.dk>
Date:	Tue, 24 Mar 2009 19:45:48 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, david@...morbit.com, npiggin@...e.de
Subject: Re: [PATCH 1/7] writeback: move dirty inodes from super_block to
	backing_dev_info

On Tue, Mar 24 2009, Jan Kara wrote:
> > This is a first step at introducing per-bdi flusher threads. We should
> > have no change in behaviour, although sb_has_dirty_inodes() is now
> > ridiculously expensive, as there's no easy way to answer that question.
> > Not a huge problem, since it'll be deleted in subsequent patches.
>   Could you maybe expand the changelog a bit? If I read the patch right
> the only thing it does is that it moves from per-sb inode lists to
> per-bdi inode lists, right? Also sync_sb_inodes() now writes all the
> inodes in the system, not just the ones for that superblock, doesn't it?

That is correct, it just moves the dirty lists to the bdi instead of
keeping them in the superblock. It does appear that this intermediate
step doesn't honor the sb passed in, later in the series it works
though. I'll get that fixed up, as the changelog mentions we should not
have much change in behaviour at this point :-)

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