On Thu, Sep 11, 2014 at 3:26 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, Sep 10, 2014 at 6:14 PM, Anand Avati <avati@xxxxxxxxxxx> wrote: > > > > > This is something beyond the libfuse API. Unless the kernel/user ABI is > > modified to present the entire 128bits with each call (i.e, both nodeID + > > generation instead of just nodeID) we are still bound to provide unique > > 64bit nodeID (and persistent for anything living across umount/mount). > > We have nodeID + generation on the kernel ABI as well. NoreID values > of 0 and 1 are reserved. The rest of the 128bit space is available. > We only have nodeID+generation in call replies when introducing a new inode (create, lookup, mkdir etc.) What if we have two inodes with different 128-bit IDs but happen to have the same upper or lower 64bits (i.e nodeIDs match, generations mismatch). First, we will have to make functions like fuse_iget start using the combination of nodeID+generation as the "key" of the search (currently it uses just nodeID as the key and generation is verified in the result - somewhat easy fix), and then we will have to present nodeID+generation as the FH for all the file operations (like open, read, setattr, getxattr) etc. Today only nodeID is sent in these file ops. This was the change I was referring to as "kernel ABI". Thanks -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
