On Tue, Jan 10, 2017 at 03:05:06PM +0530, Shyam wrote: > On 01/10/2017 02:55 PM, Niels de Vos wrote: > > On Mon, Jan 09, 2017 at 08:58:07PM +0000, Ankireddypalle Reddy wrote: > > > Neils, > > > Thanks for pointing to the sample code. The use case is to > > > use GFID as a unique key for maintaining indexing information about a > > > file when it is being backed up from GlusterFS storage. Extending GFAPI > > > to extract GFID for a file would be great. > > > As per the example If I need to find GFID for a path > > > p1/p2/p3/p4 on a glusterfs volume then should I do a look up for every > > > level? > > > LOOKUP (/)->LOOKUP(p1)-> LOOKUP(p2)-> LOOKUP(p3)-> LOOKUP(p4) > > > > No, that is not required. You can use glfs_h_lookupat() with the full > > path. Note that glfs_h_extract_handle() just does a memcpy() of the GFID > > into the given (unsigned char*), the format is of 'uuid_t'. > > The handle is an abstraction and hence we do not identify it as a GFID > per-se, isn't asking to assume the handle is the GFID breaking this > abstraction? > > IOW, if we publish this, then the handle is always the GFID and vice-versa, > are we fine with this?
I see this as a possible workaround until we offer a way to get the GFID through real function calls. Doing it like this is rather hacky, the same would be true for doing glfs_getxattr(). What the most suitable API to get a GFID is, I do not know yet. At the moment I am pondering about a glfs_xstat()/glfs_fxstat() that can get multiple flags for information to resolve. This would then fill an 'struct glfs_xstat'. Accessor methods for this struct can then return the GFID or any other extensions (location/replication awareness?). (idea based on https://lwn.net/Articles/394298/ ) Feedback most welcome :) Thanks, Niels > > > > > Attached is the modified test that shows the UUID without the need for a > > lookup of each component of the directory (a LOOKUP will be done by > > gfapi if needed). > > > > $ make CFLAGS="-lgfapi -luuid" resolve > > cc -lgfapi -luuid resolve.c -o resolve > > $ ./resolve storage.example.com media resolve.log > > Starting libgfapi_fini > > glfs_set_volfile_server : returned 0 > > glfs_set_logging : returned 0 > > glfs_init : returned 0 > > glfs_set_volfile_server : returned 0 > > glfs_set_logging : returned 0 > > glfs_init : returned 0 > > glfs_h_extract_handle : returned 0 > > UUID of /installation/CentOS-7-x86_64-Everything-1503-01.iso: > > b1b20352-c71c-4579-b678-a7a38b0e9a84 > > glfs_fini : returned 0 > > End of libgfapi_fini > > > > $ getfattr -n glusterfs.gfid -ehex > > /lan/storage.example.com/media/installation/CentOS-7-x86_64-Everything-1503-01.iso > > getfattr: Removing leading '/' from absolute path names > > # file: > > lan/storage.example.com/media/installation/CentOS-7-x86_64-Everything-1503-01.iso > > glusterfs.gfid=0xb1b20352c71c4579b678a7a38b0e9a84 > > > > HTH, > > Niels > > > > > > > > > > Thanks and Regards, > > > Ram > > > > > > > > > -----Original Message----- > > > From: Niels de Vos [mailto:[email protected]] > > > Sent: Monday, January 09, 2017 3:39 PM > > > To: Ankireddypalle Reddy > > > Cc: Gluster Devel ([email protected]); [email protected] > > > Subject: Re: [Gluster-devel] Get GFID for a file through libgfapi > > > > > > On Mon, Jan 09, 2017 at 05:53:03PM +0000, Ankireddypalle Reddy wrote: > > > > Hi, > > > > I am trying to extract the GFID for a file through libgfapi > > > > interface. When I try to extract the value of extended attribute > > > > glusterfs.gfid through libgfapi I get the errorno: 95. This works for > > > > FUSE though. Is there a way to extract the GFID for a file through > > > > libgfapi. > > > > > > It seems that this is a case where FUSE handles the xatts special. The > > > glusterfs.gfid and glusterfs.gfid.string (VIRTUAL_GFID_XATTR_KEY and > > > VIRTUAL_GFID_XATTR_KEY_STR) are specifically handled in > > > xlators/mount/fuse/src/fuse-bridge.c. > > > > > > There is a way to get the GFID, but it probably is rather a cumbersome > > > workaround for you. The handle-API is used heavily by NFS-Ganesha > > > (because NFS uses filehandles more than filenames), and extracts the GFID > > > from the 'struct glfs_object' with glfs_h_extract_handle(). A basic > > > example of how to obtain and extract the handle is in > > > https://github.com/gluster/glusterfs/blob/master/tests/basic/gfapi/bug1291259.c > > > > > > Could you explain the need for knowing the GFID in the application? We > > > can extend gfapi with fetching the GFID if that would help you. > > > > > > Niels > > > > > > > > > PS: we have a new [email protected] where external projects can ask > > > gfapi related questions. The gluster-devel list tends to be a little > > > heavy on traffic for non-Gluster developers. > > > ***************************Legal Disclaimer*************************** > > > "This communication may contain confidential and privileged material for > > > the > > > sole use of the intended recipient. Any unauthorized review, use or > > > distribution > > > by others is strictly prohibited. If you have received the message by > > > mistake, > > > please advise the sender by reply email and delete the message. Thank > > > you." > > > ********************************************************************** > > > > > > > > > > > > _______________________________________________ > > > Gluster-devel mailing list > > > [email protected] > > > http://www.gluster.org/mailman/listinfo/gluster-devel
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
