[Gluster-users] libglusterfsclient

Shehjar Tikoo shehjart at gluster.com
Mon Sep 14 06:32:45 UTC 2009


David Saez Padros wrote:
> Hi
> 
> Is libglusterfsclient a library that oone can use to build 
> applications that read/write to glusterfs file systems directly, 
> bypassing fuse ? if so, were can i find documentation/examples on 
> how to use it ?
> 

That is correct. It is like a user-space API. It allows one to build
or customize applications to avoid FUSE and kernel FS API.

There is no documentation for libglusterfsclient at this point but
booster is a user of libglusterfsclient so that is the first place
to look into. Here are some more pointers on how to use it.

When going through booster, do ignore the booster-specific code
related to mapping glusterfs file handles to POSIX integer file
descriptors and also the code for reading the FSTAB files.

To learn how to instantiate a libglusterfsclient context, see
booster/src/booster.c:booster_mount. It shows how to build a
glusterfs_init_params_t structure and pass it to glusterfs_mount.

Once the context is initialized in libglusterfsclient, you can use the
functions with names starting with glusterfs_* or glusterfs_glh_*.

The difference between the two types of API is that the first one,
i.e. glusterfs_XXXX type does not require the application to pass
a handle. A handle here is just an identifier to tell
libglusterfsclient which server(s) it should be talking to.
The reason this first API does not require a file handle is because
libglusterfsclient maintains an internal mapping for you. This mapping
is between a path prefix and the corresponding handle. So for eg, if
you call glusterfs_mount as:

glusterfs_mount ("/test/gluster", &ipars);

where ipars is a glusterfs_init_params_t, any subsequent file system
operation through the API that occurs on the /test/gluster path will
be mapped to go over the handle	stored internally for this path
prefix. This of course tells you that libglusterfsclient only supports
working with absolute paths.

The above approach is preferable when an application needs to use
multiple volfiles.

In contrast, if you're not interested in the above approach, you
use glusterfs_init API to initialize a handle and then use this
handle to operate on the files on the servers.

In the long run, we'd really prefer applications using booster since
that avoids the need to use the custom libglusterfsclient API. Just 
slip booster under an app and it works. However, the disadvantage is
that booster does not at this time support all the system calls an 
application might need. For a full list, see:

http://www.gluster.com/community/documentation/index.php/Booster_Configuration_Reference_Page

-Shehjar




More information about the Gluster-users mailing list