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