On Fri, 30 May 2014 17:55:23 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > 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:
signature.asc
Description: PGP signature
