glusterfs.git/api/src/glfs-master.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

xlator: make 'xlator_api' mandatory

2018-12-13T09:11:50+00:00

* Remove the options to load old symbol.
* keep only 'xlator_api' symbol from being exported using xlator.sym
* add xlator_api to all the xlators where its missing

NOTE: This covers all the xlators which has at least a test case
to validate its loading. If there is a translator, which doesn't
have any test, then we should probably remove that from codebase.

fixes: #164
Change-Id: Ibcdc8c9844cda6b4463d907a15813745d14c1ebb
Signed-off-by: Amar Tumballi

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

api: cleanup headers

2018-06-11T13:10:42+00:00

fix inconsistent use in headers of:
  struct glfs and glfs_t
  struct glfs_fd and glfs_fd_t
  struct glfs_object and glfs_object_t

add typedefs to headers for various struct glfs_foos, and use them, e.g.:
  struct glfs_upcall and glfs_upcall_t

fix inconsistent type naming for 'enum glfs_lock_mode_t'. (All other
enum decls are 'enum glfs_foo' not 'enum_glfs_foo_t'), and add
typedefs for all enums, and use them.

style, replace tabs with spaces and follow return value style, i.e.:
  int
  pub_glfs_foo()
instead of:
  int pub_glfs_foo()

Update copyright dates, substantial new work has been done since 2012

Change-Id: I0a9654486ea132efde7977b655799fb37887b1d5
Updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY

gfapi: Fix IO error caused when there is consecutive graph switches

2016-08-10T10:40:58+00:00

This is part 2 of the fix, the part 1 can be found at:
http://review.gluster.org/#/c/14656/

Problem:
=======
Consider a race between, __glfs_active_subvol() and graph_setup().
Lets say @TIME T1:
fs->active_subvol = A
fs->next_subvol = B
__glfs_active_subvol()                //under lock fs->mutex
{
  ....
  new_subvol = fs->next_subvol       //which is B
  ....                               //Start migration from A to B
  __glfs_first_lookup(){
     ....
     unlock fs->mutex                //@TIME T2
     network fop
     lock fs->mutex
     ....
  }
  ....                                //migration continue on B
  fs->active_subvol = fs->next_subvol //which is C (explained below)
  ....
}

@Time T2, lets say in another thread, graph_setup() is called with C,
note that at T2, fs->mutex is unlocked.

graph_stup(C...)
{
  lock fs->mutex
  ....
  if (fs->next_subvol)                // which is B
      destroy subvol (fs->next_subvol)
  ....
  fs->next_subvol = C
  ....
  unlock fs->mutex
}

Thus at the end of this,
fs->old_subvol = A;
fs->active_subvol = C;
fs->next_subvol = NULL;
which is wrong, as B completed migration, but was destroyed by
graph_setup, and C never was migrated.

Solution:
=========
Any new graph can be in one of the 2 states:
- Picked for migration, migration in progress (fs->mip_subvol)
- Not picked so far for migration (fs->next_subvol)
graph_setup() updates fs->next_subvol only, __glfs_active_subvol()
moves fs->next_subvol to fs->mip_subvol and fs->next_subvol = NULL
atomically, and then once the migration is complete, make that the
fs->active_subvol

Change-Id: Ib6ff0565105c5eedb912a43da4017cd413243612
BUG: 1343038
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/14722
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Niels de Vos

gfapi: Fix IO error caused when there is consecutive graph switches

2016-06-16T11:57:42+00:00

Issue:
Consider a simple situation, where glfs_init() is done, i.e. initial
graph is up. Now perform 2 volume sets that results in 2 client side
graph changes. After this perform some IO, the IO fails with ENOTCON.
The only way to recover this client is i guess another graph switch
or restart.

What actually is happening from code perspective:
Initial graph lets say A, followed by 2 consecutive graph switches
to B and C without any IO those two switches.

- graph_setup (A) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = A

- glfs_init() results in fs->active_subvol = A, fs->next_subvol = NULL

- graph_setup (B) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = B

- graph_setup (C) as a result of GF_EVENT_CHILD_UP, and
fs->next_subvol = C. It also sees that the previous graph B was never
set as fs->active_subvol, i.e. no IO or anything happened on B, so
can safely send GF_EVENT_PARENT_DOWN (by calling glfs_subvol_done(B)).
This parent down on B, results in child_down(B), which is fine.
But child_down also triggers graph_setup(B).

- graph_setup(B) as a result of GF_EVENT_CHILD_DOWN, and
fs->next_subvol = B, and GF_EVENT_PARENT_DOWN on C as explained
above. This again leads to GF_EVENT_CHILD_DOWN on C.

- graph_setup(C) as a result of GF_EVENT_CHILD_DOWN, and
fs->next_subvol = C, and GF_EVENT_PARENT_DOWN on B as explained
above.

Thus both the graphs B and C are disconnected, and hence the ENOTCON

Solution:
Remove the call to graph_setup() when the event is GF_EVENT_CHILD_DOWN.
It don't see any reason why graph_setup should be called when there is
child_down. Not sure what the original reason was, to have graph_setup
in child_down. git hostory shows the first patch itself had this call.

Change-Id: I9de86555f66cc94a05649ac863b40ed3426ffd4b
BUG: 1343038
Signed-off-by: Poornima G 
Reviewed-on: http://review.gluster.org/14656
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

gfapi: Add xlator_cbks fops in gfapi

2016-02-24T00:59:08+00:00

Change-Id: I1fe5dd757e65206f92e0a867b43b49a3c0f2d4cf
BUG: 1311124
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13499
Smoke: Gluster Build System 
Reviewed-by: Jeff Darcy 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

build: do not #include "config.h" in each file

2015-05-29T12:43:17+00:00

Instead of including config.h in each file, and have the additional
config.h included from the compiler commandline (-include option).

When a .c file tests for a certain #define, and config.h was not
included, incorrect assumtions were made. With this change, it can not
happen again.

BUG: 1222319
Change-Id: I4f9097b8740b81ecfe8b218d52ca50361f74cb64
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10808
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Pranith Kumar Karampuri

libgfapi : port gfapi to new logging framework

2015-04-28T12:46:31+00:00

Change-Id: Iaa0a92f82b9a0a26eda1a8d72b3b66ce66fab443
BUG: 1194640
Signed-off-by: Humble Devassy Chirammal 
Reviewed-on: http://review.gluster.org/9918
Tested-by: Gluster Build System 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Raghavendra Talur 
Reviewed-by: soumya k 
Reviewed-by: Niels de Vos