Christoph, On Fri, Jan 10, 2014 at 01:31:48AM -0800, Christoph Hellwig wrote: > On Fri, Jan 10, 2014 at 12:06:42AM +0000, Al Viro wrote: > > Check what XFS is doing ;-/ That's where those call_rcu() have come from. > > Sure, we can separate the simple "just do call_rcu(...->free_inode)" case > > and hit it whenever full ->free_inode is there and ->destroy_inode isn't. > > Not too pretty, but removal of tons of boilerplate might be worth doing > > that anyway. But ->destroy_inode() is still needed for cases where fs > > has its own idea of inode lifetime rules. Again, check what XFS is doing > > in that area... > > Btw, I'd really love to get rid of the XFS ->destroy_inode abuse, it's > been a long time thorn in the flesh. I believe this behavior is related to freeing of an inode cluster. > What's really needed there to make XFS behave more similar to everyone > else is a way for the filesystem to say: "I can't actually free this > inode right now, but I'll come back to you later". This test might read something like: "If my link count has gone to zero, and I am the last inode in my cluster to be freed, and there are other inodes from my cluster incore, I cannot be freed." Should be doable. Maybe there are other reasons. -Ben -- 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
