<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 3:26 AM, Miklos Szeredi <span dir="ltr"><<a href="mailto:miklos@szeredi.hu" target="_blank">miklos@szeredi.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 10, 2014 at 6:14 PM, Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
<br>
><br>
> This is something beyond the libfuse API. Unless the kernel/user ABI is<br>
> modified to present the entire 128bits with each call (i.e, both nodeID +<br>
> generation instead of just nodeID) we are still bound to provide unique<br>
> 64bit nodeID (and persistent for anything living across umount/mount).<br>
<br>
</span>We have nodeID + generation on the kernel ABI as well. NoreID values<br>
of 0 and 1 are reserved. The rest of the 128bit space is available.<br></blockquote><div><br></div><div>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".</div><div><br></div><div>Thanks</div><div><br></div></div></div></div>