xfs
[Top] [All Lists]

Re: [PATCH 0/5] xfs: more patches for 3.13

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH 0/5] xfs: more patches for 3.13
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 18 Nov 2013 06:48:30 +1100
Cc: Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52866008.4010309@xxxxxxxxxxx>
References: <1383280040-21979-1-git-send-email-david@xxxxxxxxxxxxx> <20131106230133.GX1935@xxxxxxx> <20131107015706.GM6188@dastard> <5282D2D3.3040601@xxxxxxxxxxx> <20131114011610.GM6188@dastard> <528657BB.8090206@xxxxxxxxxxx> <52866008.4010309@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Nov 15, 2013 at 11:55:20AM -0600, Eric Sandeen wrote:
> 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?"

Especially as it requires 2^32 modifications to first be made to the
file before there's even the possibility of a high word race on a
read and then there's only one increment we could race with before
it doesn't chnge again for another 2^32 modifications.

Hence, at 1 in 4 billion modifications potentially causing a problem,
I'd agree with the "so rare we don't care" assessment.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>