[Linux-cachefs] Storing inode index key in fscache_cookie struct

[Steve French]

For SMB2/SMB3 (and CIFS).

"IndexNumber" is 8 bytes.

"A 64-bit signed integer that contains the 8-byte file reference
number for the file. This number MUST be assigned by the file system
and is unique to the volume on which the file or directory is located"
 (see MS-FSCC 2.4.20 e.g.)

But .. if you want it to be unique across the system you need to know
what server volume it is on (or alternatively know which superblock it
is on).  Volume Serial Number is 4 bytes but is usually unique but not
required to be unique by the protocol.  Perhaps best to simply rely on
which volume the client thinks it is on rather than appending the
extra four bytes.

So 8 bytes would likely be sufficient to uniquely identify any
CIFS/SMB2/SMB3 inode, as long as you know which superblock.

On Tue, Feb 17, 2015 at 8:47 AM, David Howells <dhowells at redhat.com> wrote:
> I think that I'm going to have to store the inode index key in the
> fscache_cookie struct so that I can deal with some apparent circumstances
> where a filesystem appears to contain two active inodes that refer to the same
> server object.
>
> This seems to have happened with NFS and CIFS.  You get something that looks
> like:
>
> CacheFiles: Error: Unexpected object collision
> CacheFiles: object: OBJ1c
> CacheFiles: objstate=LOOK_UP_OBJECT fl=8 wbusy=2 ev=0[0]
> CacheFiles: ops=0 inp=0 exc=0
> CacheFiles: parent=ffff8800d9d96140
> CacheFiles: cookie=ffff8800d03bd230 [pr=ffff8800cc1ca000 nd=ffff8800cb4a2490 fl=27]
> CacheFiles: key=[8] '40a0080501090000'
> CacheFiles: xobject: OBJ1a
> CacheFiles: xobjstate=WAIT_FOR_CMD fl=38 wbusy=0 ev=0[6d]
> CacheFiles: xops=0 inp=0 exc=0
> CacheFiles: xparent=ffff8800d9d96140
> CacheFiles: xcookie=ffff8800d03bd190 [pr=ffff8800cc1ca000 nd=ffff8800cb4aad00 fl=22]
> CacheFiles: xkey=[8] '40a0080501090000'
> ------------[ cut here ]------------
> kernel BUG at fs/cachefiles/namei.c:196!
>
>
> Both objects appear to be valid, but key and xkey are the same.
>
>
> What I propose to do is to take a copy of the index key and store it in the
> cookie in fscache_acquire_cookie() and keep all of the cookies in an
> associative array.  Then when fscache_acquire_cookie() is called, it checks
> the index key it obtained against the associative array and rejects attempts
> to use a duplicate key right up front rather down in the bowels of the cache
> implementation where it's much harder to recover.
>
> Now, what I was thinking of is to create 16 bytes of space in the cookie and
> to use a flag to indicate whether this contains the index key or a pointer to
> the index key.  AFS and Ceph can both fit their inode keys within this, but
> NFS's inode index keys are NFS FH's and can be much larger.  Would it make
> sense to make this space larger in the hope of fitting in NFS FH's?
>
> David



-- 
Thanks,

Steve