<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 7:20 AM, Miklos Szeredi <span dir="ltr"><<a href="mailto:miklos@szeredi.hu" target="_blank">miklos@szeredi.hu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> This would be a challenge with any FUSE based filesystem which has<br>
>> persistent filehandles larger than 64bit.<br>
<br>
</span>Fuse does provide a total of 128bits of file handle identification<br>
with nodeID + generation, with some of that number-space reserved for<br>
special uses, unfortunately.<br>
<br>
Would be nice to provide for arbitrary file handle lengths. Will<br>
look into that, at least for the libfuse-3.0 API.<br></blockquote><div><br></div><div>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). This is perhaps the biggest reason why GlusterFS implemented its own NFS server for v3 and uses NFS-Ganesha for v4, instead of using kNFSd.</div><div><br></div><div>Thanks</div></div></div></div>