On Thu, Aug 06 2009, Christoph Hellwig wrote: > On Thu, Jul 30, 2009 at 11:23:56PM +0200, Jens Axboe 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. > > Looking at this again and again I don't really like this at all. What > is the problem with having per-bdi flushing threads that just iterate > a list of superblocks per-bdi and then the inodes from there? That > would keep a lot of the calling conventions much more logical, as we > have to writeback data per-sb for all data integrity and some other > writes. OK, so you'd prefer leaving the super block lists in place and rather have the super blocks hanging off the bdi? What about file systems that support more than one block device per mount, like btrfs? Can we assume that they will forever provide a single bdi backing? btrfs currently has this, just wondering about future implications. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
