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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
