[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