Re: Live lock in silly-rename.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 11 Jun 2014 10:21:02 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
wrote:

> On Thu, Jun 05, 2014 at 10:34:23AM +1000, NeilBrown wrote:
> > On Wed, 4 Jun 2014 18:05:31 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
> > wrote:
> > 
> > > On Wed, Jun 04, 2014 at 05:39:26PM +1000, NeilBrown wrote:
> > > > Below is my suggestion.  It seems easy enough.  It even works.
> > > 
> > > Woah!
> > > 
> > > Anyway, looks reasonable to me, and it fixes an immediate problem so I'm
> > > inclined to just apply.
> ...
> > And if you are going to apply it, you'll want:
> > 
> >    Signed-off-by: NeilBrown <neilb@xxxxxxx>
> 
> Oh, gah, then I forgot to actually apply.

The best laid plan of mice ....

> 
> Anyway, it's a reasonably self-contained fix for an important bug so
> I'll send it as part of a later bugfix pull request.
> 
> I thought it could also use a more explicit description of the resulting
> problem, so I added:
> 
> 	... so further delegations should not be handed out.
> 
> 	The current code fails to do so, and the result is effectively a
> 	live-lock under some workloads: a client attempting a
> 	conflicting operation on a read-delegated file receives
> 	NFS4ERR_DELAY and retries the operation, but by the time it
> 	retries the server may already have given out another
> 	delegation.

Looks good, thanks.

NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux