[GEDI] [Gluster-devel] Get GFID for a file through libgfapi

[Shyam]

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?

>
> 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/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 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."
>> **********************************************************************
>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel