On Fri, Jul 20, 2018 at 10:41:07AM -0400, Brian Foster wrote: > Ok.. on this one, running some tests shows that pretty much all dfops > joined bufs/inodes are essentially held in the transaction (which would > probably be a bug if that were not the case). That's what I'd expect. > The opposite is also true > for buffers, because a held buffers must also be held in subsequent > transactions to ensure the caller still has a reference after dfops > completion. OTOH, there are some places where inodes are joined to a > transaction with lock_flags == 0 and dfops are run without the inode > joined to the dfops. I don't necessarily think this is a bug for the > inode case because the caller still owns the inode lock, we just don't > relog it across the series of transactions required for dfops > completion. I suspect many of those are a bug. Yes, we could have deferred ops that don't need the inode, but in general we'd want the same objects for the deferred inode. That being said we could always have an indicator for that case, but I'd rather make it opt-in than opt-out. -- 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
