Re: Live lock in silly-rename.

[NeilBrown <neilb@suse.de>]

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

On Wed, 4 Jun 2014 18:05:31 -0400 "J. Bruce Fields" <bfields@fieldses.org>
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.
> 
> The vfs knows about delegations at this point, and there's been this
> vague idea we might give user space servers request them at some point,
> so we might eventually want this code to fs/locks.c instead of here.
> 
> Wonder if filehandle is the right thing to hash on, as opposed to inode
> number, or inode pointer, or something else?

I pondered that question for a short while too.

inode number didn't seem right as you might export two filesystems with the
same inode numbers.
inode pointer didn't seem right as it could fall out of the cache and
something else could be loaded in the same place.

filehandle isn't perfect as it isn't 100% unique (you can have two
filehandles with different 'types' for the one inode).  But I felt it was
close enough in practice.

superblock pointer plus inode number plus inode generation number would
probably be perfect, but that is so close to the filehandle which was already
easily available, it seems silly not to just use filehandle.

Certainly if the code ever wants to move to locks.c, the question can be
revisited.

And if you are going to apply it, you'll want:

   Signed-off-by: NeilBrown <neilb@suse.de>

I forgot that in the original.

Thanks,
NeilBrown

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