glusterfs.git/api/src/glfs.h, branch v3.6.9

api: versioned symbols in libgfapi.so for compatibility

2015-03-04T07:32:16+00:00

Use versioned symbols to keep libgfapi at libgfapi.so.0.0.0

Revisited to address broken build on Mac OS X

See http://review.gluster.org/9055

Change-Id: I0f26668898749f57b61490b18f1f04c42996225d
BUG: 1165129
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/9145
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Ravishankar N 
Reviewed-by: Raghavendra Bhat

api: non glibc c++ systems do not define __THROW

2014-05-17T18:54:33+00:00

Let __THROW be defined conditionally for more portability

Change-Id: I6e7cb1eb59b84988e155e9a8b696e842b7ff8f7f
BUG: 1089172
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/7757
Tested-by: Gluster Build System 
Reviewed-by: Emmanuel Dreyfus 
Reviewed-by: Anand Avati

libgfapi: Added support to fetch volume info from glusterd and store in glfs object.

2014-05-11T09:47:42+00:00

Defined new APIs in the libgfapi module, given a glfs object,
 * to send handshake RPC call to glusterd process to fetch UUID of the volume
 * store it in the glusterfs_context linked to the glfs object.
 * to parse UUID from its cannonical string format into 16-byte array
   before sending it to the libgfapi users.

Defined a RPC call in glusterd which can be used to query volume related
info by other processes using 'clnt_handshake_procs'.

Note - Currently this RPC call to glusterd process is used only to fetch UUID.
But it can be extended to get other volume related structures as well.

In addition to the above, defined a new variable to keep track of such handshake
RPCs still in progress to make sure all the corresponding RPC callbacks have been
processed before libgfapi returns the glfs object initialized.

Also bumping up the GFAPI current version number since there is a new API
"glfs_get_volume_id" defined and exposed by libgfapi as part of these changes.

Change-Id: I303f76d7177d32d25bdb301b1dbcf5cd73f42807
BUG: 1090363
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/7218
Reviewed-by: Anand Avati 
Reviewed-by: Harshavardhana 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gfapi: glfs_set_volfile_server() now entertains multiple calls

2014-04-01T22:06:32+00:00

Previous API:

glfs_set_volfile_server (..., const char *host, ...) - single call

New API's:

glfs_set_volfile_server (..., const char *host1, ...)
glfs_set_volfile_server (..., const char *host2, ...)

Multiple calls to this function with different volfile servers,
port or transport-type would create a list of volfile servers
which would be polled during `volfile_fetch_attempts()`

glfs_unset_volfile_server (..., const char *host, ...) to remove
a server from the list (this is provided for future usage)

Change-Id: I313efbd3efbd0214e2a71465f33195788df406cc
BUG: 986429
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/7317
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Anand Avati

api: add glfs_get_volfile

2014-03-06T05:29:42+00:00

From the API-header description:

> Sometimes it's useful e.g. for scripts to see the volfile, so that
> they can parse it and find subvolumes to do things like split-brain
> resolution or custom layouts.  The API here was specifically intended
> to make access e.g. from Python as simple as possible.
>
> Note that the volume must be started (not necessarily mounted) for
> this to work.

Change-Id: If3f55ee9611cdf4b77aa53659f0af0d21957817d
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/7183
Reviewed-by: Anand Avati 
Tested-by: Gluster Build System

gfapi: add THROW [(attribute) ((nothrow))] to fn decls for C++ users.

2013-12-03T18:01:59+00:00

Off hand I don't know of anything written in C++ that is or could be a user
of gfapi.

Never the less, it's possible that one could exist, or be written, and
marking the library entry points is a) friendly, b) possibly allows the
C++ compiler to generate better code, and c) is a good practice when
writing APIs that might be consumed by C++ applications. Considering we
already take the first step and use __BEGIN_DECLS/__END_DECLS to be C++
friendly, we should take the extra step

Change-Id: Ib319ecaa452a46f258a9c6e8c7221454d2fefd0f
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/6393
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

zerofill: Change the type of len argument of glfs_zerofill() to off_t

2013-11-15T07:29:48+00:00

glfs_zerofill() can be potentially called to zero-out entire file and
hence allow for bigger value of length parameter.

Change-Id: I75f1d11af298915049a3f3a7cb3890a2d72fca63
BUG: 1028673
Signed-off-by: Bharata B Rao 
Reviewed-on: http://review.gluster.org/6266
Tested-by: Gluster Build System 
Reviewed-by: M. Mohan Kumar 
Tested-by: M. Mohan Kumar 
Reviewed-by: Anand Avati

gfapi: introduce glfs_readdir() and glfs_readdirplus() APIs

2013-11-13T18:48:18+00:00

Change-Id: I6b233bf647585675f233898351bf593f251716cc
BUG: 839950
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/6201
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Talur

glusterfs: zerofill support

2013-11-11T05:25:49+00:00

Add support for a new ZEROFILL fop. Zerofill writes zeroes to a file in
the specified range. This fop will be useful when a whole file needs to
be initialized with zero (could be useful for zero filled VM disk image
provisioning or  during scrubbing of VM disk images).

Client/application can issue this FOP for zeroing out. Gluster server
will zero out required range of bytes ie server offloaded zeroing. In
the absence of this fop,  client/application has to repetitively issue
write (zero) fop to the server, which is very inefficient method because
of the overheads involved in RPC calls  and acknowledgements.

WRITESAME is a  SCSI T10 command that takes a block of data as input and
writes the same data to other blocks and this write is handled
completely within the storage and hence is known as offload . Linux ,now
has support for SCSI WRITESAME command which is exposed to the user in
the form of BLKZEROOUT ioctl.  BD Xlator can exploit BLKZEROOUT ioctl to
implement this fop. Thus zeroing out operations can be completely
offloaded to the storage device , making it highly efficient.

The fop takes two arguments offset and size. It zeroes out 'size' number
of bytes in an opened file starting from 'offset' position.

This patch adds zerofill support to the following areas:
	- libglusterfs
	- io-stats
	- performance/md-cache,open-behind
	- quota
	- cluster/afr,dht,stripe
	- rpc/xdr
	- protocol/client,server
	- io-threads
	- marker
	- storage/posix
	- libgfapi

Client applications can exloit this fop by using glfs_zerofill introduced in
libgfapi.FUSE support to this fop has not been added as there is no system call
for this fop.

Changes from previous version 3:
* Removed redundant memory failure log messages

Changes from previous version 2:
* Rebased and fixed build error

Changes from previous version 1:
* Rebased for latest master

TODO :
     * Add zerofill support to trace xlator
     * Expose zerofill capability as part of gluster volume info

Here is a performance comparison of server offloaded zeofill vs zeroing
out using repeated writes.

[root@llmvm02 remote]# time ./offloaded aakash-test log 20

real	3m34.155s
user	0m0.018s
sys	0m0.040s
[root@llmvm02 remote]# time ./manually aakash-test log 20

real	4m23.043s
user	0m2.197s
sys	0m14.457s
[root@llmvm02 remote]# time ./offloaded aakash-test log 25;

real	4m28.363s
user	0m0.021s
sys	0m0.025s
[root@llmvm02 remote]# time ./manually aakash-test log 25

real	5m34.278s
user	0m2.957s
sys	0m18.808s

The argument log is a file which we want to set for logging purpose and
the third argument is size in GB .

As we can see there is a performance improvement of around 20% with this
fop.

Change-Id: I081159f5f7edde0ddb78169fb4c21c776ec91a18
BUG: 1028673
Signed-off-by: Aakash Lal Das 
Signed-off-by: M. Mohan Kumar 
Reviewed-on: http://review.gluster.org/5327
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

gfapi: object handle based API extensions

2013-10-11T19:16:46+00:00

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.

Towards this we need 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.

This code drop is an initial implementation of the proposed APIs.

The new APIs are implemented as glfs_h_XXX variants in the file
glfs-handleops.c to mirror glfs-fops.c style. The code leverages holding
onto inode references and doling these out as opaque/cookie type objects to
the callers, to enable them to be used as handles in other operations.

An fd based approach was considered, but due to the extra footprint that
the fd structure and its counterparts would incur, this was dropped to take
the approach of holding inode references themselves.

Tested by extending glfsxmp.c to invoke and exercise the added APIs, and
further tested with a reference integration of the same as an FSAL with NFS
Ganesha.

Change-Id: I23629c99e905b54070fa2e6565147812e5f3fa5d
BUG: 1016000
Signed-off-by: R.Shyamsundar 
Reviewed-on: http://review.gluster.org/5936
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati