[Gluster-devel] [fuse-devel] Feature proposal - FS-Cache support in FUSE

Anand Avati avati at gluster.org
Thu Sep 11 17:17:53 UTC 2014


On Thu, Sep 11, 2014 at 3:26 AM, Miklos Szeredi <miklos at szeredi.hu> wrote:

> On Wed, Sep 10, 2014 at 6:14 PM, Anand Avati <avati at gluster.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140911/6e63fd3c/attachment.html>


More information about the Gluster-devel mailing list