glusterfs.git/xlators/lib/src/libxlator.c, branch v7.1

multiple files: another attempt to remove includes

2019-06-14T16:50:32+00:00

There are many include statements that are not needed.
A previous more ambitious attempt failed because of *BSD plafrom
(see https://review.gluster.org/#/c/glusterfs/+/21929/ )

Now trying a more conservative reduction.
It does not solve all circular deps that we have, but it
does reduce some of them. There is just too much to handle
reasonably (dht-common.h includes dht-lock.h which includes
dht-common.h ...), but it does reduce the overall number of lines
of include we need to look at in the future to understand and fix
the mess later one.

Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f
updates: bz#1193929
Signed-off-by: Yaniv Kaul

Replace memdup() with gf_memdup()

2019-04-12T13:08:28+00:00

memdup() and gf_memdup() have the same implementation. Removed one API
as the presence of both can be confusing.

Change-Id: I562130c668457e13e4288e592792872d2e49887e
updates: bz#1193929
Signed-off-by: Vijay Bellur

Multiple files: reduce work while under lock.

2019-01-29T09:27:22+00:00

Mostly, unlock before logging.
In some cases, moved different code that was not needed
to be under lock (for example, taking time, or malloc'ing)
to be executed before taking the lock.

Note: logging might be slightly less accurate in order, since it may
not be done now under the lock, so order of logs is racy. I think
it's a reasonable compromise.

Compile-tested only!
updates: bz#1193929
Signed-off-by: Yaniv Kaul 

Change-Id: I2438710016afc9f4f62a176ef1a0d3ed793b4f89

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

cluster/ec: Minimize usage of EIO error

2015-07-28T11:12:17+00:00

Change-Id: I82e245615419c2006a2d1b5e94ff0908d2f5e891
BUG: 1245276
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/11741
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: NetBSD Build System

Avoid conflict between contrib/uuid and system uuid

2015-04-04T17:48:35+00:00

glusterfs relies on Linux uuid implementation, which
API is incompatible with most other systems's uuid. As
a result, libglusterfs has to embed contrib/uuid,
which is the Linux implementation, on non Linux systems.
This implementation is incompatible with systtem's
built in, but the symbols have the same names.

Usually this is not a problem because when we link
with -lglusterfs, libc's symbols are trumped. However
there is a problem when a program not linked with
-lglusterfs will dlopen() glusterfs component. In
such a case, libc's uuid implementation is already
loaded in the calling program, and it will be used
instead of libglusterfs's implementation, causing
crashes.

A possible workaround is to use pre-load libglusterfs
in the calling program (using LD_PRELOAD on NetBSD for
instance), but such a mechanism is not portable, nor
is it flexible. A much better approach is to rename
libglusterfs's uuid_* functions to gf_uuid_* to avoid
any possible conflict. This is what this change attempts.

BUG: 1206587
Change-Id: I9ccd3e13afed1c7fc18508e92c7beb0f5d49f31a
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/10017
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

xlators/lib: Handle NULL 'name' for marker xattrs

2015-03-27T07:21:33+00:00

Change-Id: I18f00b7e92f483673250821c457d1e8be2eef081
BUG: 1200372
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/10015
Tested-by: Gluster Build System 
Reviewed-by: Aravinda VK 
Reviewed-by: Vijay Bellur

libxlator: Change marker xattr handling interface

2015-03-25T18:10:40+00:00

- Changed the implementation of marker xattr handling to take just a
  function which populates important data that is different from
  default 'gauge' values and subvolumes where the call needs to be
  wound.
- Removed duplicate code I found while reading the code and moved it to
  cluster_marker_unwind. Removed unused structure members.
- Changed dht/afr/stripe implementations to follow the new implementation
- Implemented marker xattr handling for ec.

Change-Id: Ib0c3626fe31eb7c8aae841eabb694945bf23abd4
BUG: 1200372
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/9892
Tested-by: Gluster Build System 
Reviewed-by: Xavier Hernandez 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Ravishankar N 
Reviewed-by: Vijay Bellur

libxlator: Make sure marker_xattr is valid

2015-03-09T10:15:06+00:00

Problem:
marker_xattr is allocated only when the op_ret is 0. If the final response is
a failure, then the marker time is dict_set with key as NULL. this will be
changed to ref: by dict_set, so the value won't appear on the
marker-key when the getxattr_cbk is in dht. So dht unwinds with failure EINVAL.

Fix:
Always populate marker_xattr. Fixed dict mem-leak as well.

Change-Id: I1752f277a8852c47b0a2ccce9fd72ee88456ac02
BUG: 1199406
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/9817
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G