[Gluster-devel] RFC/Review: libgfapi object handle based extensions

[Shyamsundar Ranganathan]

Hi,

There is an ongoing effort to integrate NFS Ganesha ( 
https://github.com/nfs-ganesha/nfs-ganesha/wiki ) with GlusterFS as one of the 
file system back ends. This enables Gluster to move from supporting NFSv3 to 
NFSv3/4 (and possibly 4.1 in the future).

Towards this we need some extensions to gfapi that can handle object based 
operations. Meaning, instead of using full paths or relative paths from cwd, it 
is required that we can work with APIs, like the *at POSIX variants, to be able 
to create, lookup, open etc. files and directories. Hence the objects are the 
files or directories themselves and we give out handles to these objects that 
can be used for further operations.

The need for object handles come from the NFS protocol itself that operates on 
the wire handles for various files or directories (RFC 1813 Pg 20 (struct 
nfs_fh3)). It is possible to have a name to wire handle cache at the NFS server 
to dole out unique wire handles for the files and directories, but it is 
equally good to leverage the GFID of the objects instead, just like the current 
Gluster NFSv3 implementation. Hence the proposed extensions as below.

We have a reference implementation of the proposed APIs as well, that I will 
post as a follow up for review and comments to gerrit.

New APIs (samples):
1) struct glfs_object *glfs_h_lookupat (struct glfs *fs, struct glfs_object 
*parent, const char *path, struct stat *stat)

   In: fs, parent, path
   Out: stat, struct glfs_object * (handle to the object)

   struct glfs_object: This is an opaque object containing a pointer to the 
inode of the actual object looked up or the parent under which to lookup (as 
the case may be) and the gfid of the object.

struct glfs_object {
        inode_t         *inode;
        uuid_t          gfid;
};

   The code would still use syncops to make the FOPs, with the loc_t filled in 
with information from the inode (and a further glfs_loc_touchup) passed in as 
is applicable for the syncop call.

2) int glfs_h_getattrs (struct glfs *fs, struct glfs_object *object, struct 
stat *stat)

   In: fs, object
   Out: stat

   Again using the object->inode, fill up the required feilds in loc_t and get 
the attributes of the object with a lookup or a stat syncop.

3) struct glfs_fd *glfs_h_open (struct glfs *fs, struct glfs_object *object, 
int flags)

   In: fs, object, flags
   Out: glfs_fd

   This is a call to transition from the object handle to an fd for any further 
fd based gfapi operation.

4) struct glfs_object *glfs_h_create_from_gfid (struct glfs *fs, struct 
glfs_gfid *id, struct stat *sb)

   In: fs, gfs_gfid
   Out: stat, struct glfs_object *

   This is to get an object handle given a GFID as input.

NOTE: The structure below needs to change to a singly allocated buffer as 
needed, so this is a current reference only structure definition
struct glfs_gfid {
        unsigned char *id;
        int len;
};

Issues (possible):
- Links will have the same GFID, hence a pure GFID based handing out of object 
handles may not essentially be right or complete
- The glfs_object need not have the gfid within it, as it holds a reference to 
the inode (which inturn has the gfid)
- We do need the APIs to extend themselves to do any ID based operations, say 
creating with a specific UID/GID rather than the running process UID/GID that 
can prove detrimental in a multi threaded, multi connection handling server 
protocol like the NFS Ganesha implementation

Request comments, suggestions or other needs that these APIs can be put to. To 
help arrive at a clearer (cleaner) common set for consumption in the current 
NFS Ganesha work and other modules that may use these variants.

Regards,
Shyam