[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gluster-devel] RFC/Review: libgfapi object handle based extensions
From: |
Shyamsundar Ranganathan |
Subject: |
[Gluster-devel] RFC/Review: libgfapi object handle based extensions |
Date: |
Fri, 13 Sep 2013 04:18:19 -0400 (EDT) |
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] RFC/Review: libgfapi object handle based extensions,
Shyamsundar Ranganathan <=
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Anand Avati, 2013/09/13
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Shyamsundar Ranganathan, 2013/09/16
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Anand Avati, 2013/09/30
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Anand Avati, 2013/09/30
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Shyamsundar Ranganathan, 2013/09/30
- Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions, Anand Avati, 2013/09/30