Re: Live lock in silly-rename.

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

 



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."

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

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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