glusterfs.git/xlators/mgmt/glusterd/src/glusterd-geo-rep.c, branch v3.4.2qa3

glusterd: big lock - a coarse-grained locking to prevent races

2013-04-17T12:48:50+00:00

There are primarily three lists that are part of glusterd process,
that are concurrently accessed. Namely, priv->volumes, priv->peers
and volinfo->bricks_list.

Big-lock approach
-----------------
WHAT IS IT?
Big lock is a coarse-grained lock which protects all three
lists, mentioned above, from racy access.

HOW DOES IT WORK?
At any given point in time, glusterd's thread(s) are in execution
_iff_ there is a preceding, inbound network event. Of course, the
sigwaiter thread and timer thread are exceptions.
A network event is an external trigger to glusterd, via the epoll
thread, in the form of POLLIN and POLLERR.
As long as we take the big-lock at all such entry points and yield
it when we are done, we are guaranteed that all the network events,
accessing the global lists, are serialised.

This amounts to holding the big lock at
- all the handlers of all the actors in glusterd. (POLLIN)
- all the cbks in glusterd. (POLLIN)
- rpc_notify (DISCONNECT event), if we access/modify
  one of the three lists. (POLLERR)

In the case of synctask'ized volume operations, we must remember that,
if we held the big lock for the entire duration of the handler,
we may block other non-synctask rpc actors from executing.
For eg, volume-start would block in PMAP SIGNIN, if done incorrectly.
To prevent this, we need to yield the big lock, when we yield the
synctask, and reacquire on waking up of the synctask.

BUG: 948686
Change-Id: I429832f1fed67bcac0813403d58346558a403ce9
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/4835
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Made gsync set use synctask framework

2013-02-09T03:09:29+00:00

Change-Id: I409fa5a9f55434ece47a8a51d4812d3eca42d269
BUG: 852147
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/4473
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: do dict unref after sending reply to cli

2013-02-03T20:35:09+00:00

This patch channelizes dict unrefs of dictionaries created from the cli
req during volume ops to one common function - glusterd_to_cli() - which
is guaranteed to be called irrespective of whether the command succeeds
or fails.

This patch also removes extra unrefs at a few places.

Change-Id: Ic8ba7166387b5dfd1f5ae860539e1b7093a94662
BUG: 861044
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4003
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
Reviewed-by: Anand Avati

geo-rep / glusterd: do non-blocking connect to checkpoint service

2013-01-22T06:25:53+00:00

glusterd should not hang if gsyncd ends up in some weird state

Change-Id: Ic141daa0cd05d515848c8b6c25702418e15b7599
BUG: 826512
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.org/3919
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: Add GF_ASSERT check in glusterd volume op handlers

2013-01-09T07:58:41+00:00

Change-Id: Iea6ac1e612812ba8ffc4b60899a9e574a3b09ea6
BUG: 873549
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4346
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

gsyncd / geo-rep: do not start geo-rep if replace brick is in progress

2012-12-12T00:26:52+00:00

Change-Id: I9db32544ceb6f90c8231aaf40d722f6869a72614
BUG: 861945
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/4289
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: log appropriate message when locking fails

2012-12-12T00:06:08+00:00

PROBLEM:

When a transaction is already in progress, and the user tries to
execute another glusterd operation, the second operation fails as
glusterd fails to acquire lock. But to the user, a message like
"Operation failed" does not give ample information about why the
operation failed.

FIX:

Made glusterd_op_txn_begin use and initialise error string, which is
needed to capture failure in the "lock" phase.

Also made gd_sync_task_begin set error string appropriately when
locking fails.

In the process, I had to introduce error string in some glusterd_handle_*
functions. And because I introduced error string in these handlers, I
decided to also set them in places where these handlers could possibly
fail.

HOW I TESTED IT:

For want of a better idea, I "commented out" the call to
"glusterd_unlock", recompiled glusterd and ran two glusterd volume
operations, one after the other. The second operation fails with the
message "Another transaction is in progress. Please try again after
sometime." as expected.

The tests were performed on two volume ops : one of them
synctask'ized (volume start) and the other NOT (volume create).

Change-Id: Ia862972929872ae2f053707a544824d9cadc37be
BUG: 873549
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4197
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

Fix xdr_to_generic success check

2012-12-10T05:59:56+00:00

This patch fixes the success check for xdr_to_generic function across the
codebase.

Also, cleans up the brick_op actors table in glusterfsd-mgmt.c to make sure that
the actors are called directly by rpcsvc.

Change-Id: I3086585f30c44f69f1bc83665f89e30025f76d3a
BUG: 884452
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/4278
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

geo-rep / gsyncd,glusterd: do not hardcode socket path

2012-11-29T00:54:07+00:00

... in gsyncd python code. Indeed, use the configuration
mechanism to set it suitably from glusterd.

Change-Id: I9fe2088b14d28588d1e64fe892740cc5755b8365
BUG: 868877
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.org/4143
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

gsyncd / geo-rep: include hostname in status cmd

2012-11-22T00:49:04+00:00

Including hostname of the node where geo-rep start was
initiated from. This helps any consumers of the status
command to identify and possibly issue commands on those
node(s).

Change-Id: I005083878a3a4794da3b7f3f7d2cc9d28f004e3f
BUG: 858218
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/4218
Reviewed-by: Csaba Henk 
Tested-by: Gluster Build System