Hello, Christoph. On Tue, Nov 24, 2015 at 08:54:57AM +0100, Christoph Hellwig wrote: > > Can you please explain a bit more why inode pointing to its associated > > bdi_writeback is a bad idea? The only alternative would be recording > > a key and looking up each time. We sure can do that but I don't get > > why we would want to. > > Because the writeback context really is a per-super block concept > (except for the magic block device inodes). Having another pointer With cgroup writeback, inodes belonging to the same superblock can belong to different writeback domains, so it no longer is strictly per-super block concept. > pointer in the inode (or address_space back then) lead to all kinds > of confusing bugs and life time issues, nevermind massively bloating the The bdev case is different because a bdev's lifetime doesn't coincide with the actual object it's representing but the root cause there is lower layer objects being destroyed while higher layer objects depending on them are still around. Severing inode -> lower layer object dependency may be able to solve some issues but those approaches are usually pretty brittle. The right thing to do is letting objects getting torn down in order by maintaining proper refs. > inode for no reason. But then again bloating the inode has been rather > en vogue lately anyway. How is it for no reason when there are clearly purposes for them? If the extra pointer is problematic, we can try to split sb's so that we can encode writeback domain information by pointing to per-writeback-domain split sb's but I'm not sure the added complexity would be justifiable. Thanks. -- tejun -- 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
