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

[Anand Avati]

Shyam,
Thanks for sending this out. Can you post your patches to
review.gluster.organd link the URL in this thread? That would make
things a lot more clear
for feedback and review.

Avati


On Fri, Sep 13, 2013 at 1:18 AM, Shyamsundar Ranganathan <
srangana at redhat.com> wrote:

> 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
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130913/01b6375a/attachment-0001.html>