On 11/15/13, 11:19 AM, Eric Sandeen wrote: > On 11/13/13, 7:16 PM, Dave Chinner wrote: > >> That's client side, not server side, so that's the NFS client inode >> it is locking, not the server side XFS inode. > > Ah, geez, you're right. (x3) > > <snip> > >> Server side, where i_version is pulled out of an XFS inode: >> >> $ git grep i_version fs/nfsd >> fs/nfsd/nfs3xdr.c: fhp->fh_post_change = fhp->fh_dentry->d_inode->i_version; >> fs/nfsd/nfs4xdr.c: write64(p, inode->i_version); >> fs/nfsd/nfsfh.h: fhp->fh_pre_change = inode->i_version; >> $ >> >> the nfsfh.h hit is in fill_pre_wcc(), which appears to be called >> under i_mutex but not i_lock. The xdr encoding functions don't >> appear to be holding i_lock, and may be holding i_mutex, but I >> haven't looked that far. > > I'm still not sure how . . . ugh didn't mean to send this reply quite yet, sorry. Not sure how we do an unlocked read on a 32-bit machine that doesn't potentially get the wrong answer. I talked to Bruce about it a bit; nothing jumped out at us. At worst (?) it seems that if you happened to race on a read at exactly the 2^32'nd modification, you might go backwards. As Bruce says, even if so, maybe "so rare we don't care?" -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
