On Mon, Oct 17, 2016 at 10:38:49PM -0700, Darrick J. Wong wrote:
> In a way, yes. We don't need to keep it on the LRU necessarily, we
> just need it not to think "Oh, this inode has i_nlink == 0 so we can
> truncate all the blocks and free the inode" prior to the end of bmap
> intent processing.
>
> > I'd really prefer if we could just do it in our own ->drop_inode call
> > then instead of messing with MS_ACTIVE.
>
> The difficulty here is that without MS_ACTIVE, the vfs will always
> evict the inode when i_count == 0. I suppose bmap intent processing
> could bump up i_count and stash the inode somewhere to prevent the
> i_count from hitting zero until after we're done recovering the log...
> ...but otherwise I'm sorta stumped about how to do that.
Let me try to understand the issue here.
We get a final iput for an inode that recover once i_count hits zero.
We then want to hit the "if (!drop && (sb->s_flags & MS_ACTIVE)) {"
conditional there to add it to the lru, or at least not truncate it.
I guess for now we'll need MS_ACTIVE early here, yes.
So reluctantly:
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
