On Fri, Feb 12, 2010 at 01:56:47PM -0600, bpm@xxxxxxx wrote: > I chose not implement that suggestion because I prefer not to rely upon > the coincidence that the child be modified last and synced first in > knfsd. It does ot rely on that coincidence for correctness, just for a small performance optimization. > It is better that the intent of the patch be clear, and that > filesystems other than xfs also have enough information to sort out how > to sync more efficiently. knfsd shouldn't be forced to sync in a > specific order just because that's what works best for xfs. Or, mebbe > it should and I'm being thick. ;) The order of parent and child only happens in the create case where NFS does a separate ->setattr call. For all the operations handled by the filesystem parent and child are in the same transaction for every transactional filesystem. > > This keeps the calling convention quite a bit simpler, > > and also means we don't have to bother with locking two inodes or lsn > > comparisms. > > Don't need the ilock to check pincount? Ah sorry, that should have read not bothering with locking two inodes at the same time, which always is a bit troublesome. We do need to lock the inode for looking at the pincount. > > We can deal with that by either commiting the old variant to the nfs > > tree and then leaving sending Stephen a patch to fix it up in -next, > > or just not apply the xfs commit_metadata implementation yet, and wait > > for it until both the xfs and nfs trees have hit mainline. > > Yeah. I don't know who Stephen is. Stephen Rothwell is the maintainer of the linux-next tree. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
