Re: Live lock in silly-rename.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Fri, 30 May 2014 17:55:23 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Fri, May 30, 2014 at 01:44:42PM +1000, NeilBrown wrote:
> > On Thu, 29 May 2014 20:44:23 -0400 "J. Bruce Fields" <bfields@fieldses.org>
> > wrote:
> > 
> > > Yes, it's a known server bug.
> > > 
> > > As a first attempt I was thinking of just sticking a timestamp in struct
> > > inode to record the time of the most recent conflicting access and deny
> > > delegations if the timestamp is too recent, for some definition of too
> > > recent.
> > > 
> > 
> > Hmmm... I'll have a look next week and see what I can come up with.
> 
> Thanks!
> 
> If we didn't think it was worth another struct inode field, we could
> probably get away with global state.  Even just refusing to give out any
> delegations for a few seconds after any delegation break would be enough
> to fix this bug.
> 
> Or you could make it a little less harsh with a small hash table: "don't
> give out a delegation on any inode whose inode number hashes to X for a
> few seconds."

I was thinking of using a bloom filter - or possibly two.
- avoid handing out delegations if either bloom filter reports a match
- when reclaiming a delegation add the inode to the second bloom filter
- every so-often zero-out the older filter and swap them.

Might be a bit of overkill, but I won't know until I implement it.

NeilBrown

> 
> As long as the delegations can be turned down at the whim of the server,
> we've got a lot of leeway.
> 
> --b.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]