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
It does ot rely on that coincidence for correctness, just for a small
> 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.