[GEDI] [Gluster-devel] Get GFID for a file through libgfapi
Niels de Vos
ndevos at redhat.com
Tue Jan 10 11:33:21 UTC 2017
On Tue, Jan 10, 2017 at 10:42:36AM +0000, Ankireddypalle Reddy wrote:
> Neils,
> Thanks a lot. Will use this for extracting GFID.
Note that this should not be the final solution for fetching the GFID.
We will add an API for this to make it easier to use and have it well
defined and stable for the future.
Niels
>
> Ram
>
> -----Original Message-----
> From: Niels de Vos [mailto:ndevos at redhat.com]
> Sent: Tuesday, January 10, 2017 4:26 AM
> To: Ankireddypalle Reddy
> Cc: Gluster Devel (gluster-devel at gluster.org); integration at gluster.org
> Subject: Re: [Gluster-devel] Get GFID for a file through libgfapi
>
> 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'.
>
> 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:ndevos at redhat.com]
> > Sent: Monday, January 09, 2017 3:39 PM
> > To: Ankireddypalle Reddy
> > Cc: Gluster Devel (gluster-devel at gluster.org); integration at gluster.org
> > 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/bug
> > 1291259.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 integration at gluster.org 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."
> > **********************************************************************
> >
> ***************************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."
> **********************************************************************
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/integration/attachments/20170110/27155ed9/attachment-0002.sig>
More information about the integration
mailing list