glusterfs.git/xlators/mgmt/glusterd/src/glusterd.c, branch v3.4.6beta2

mgmt/glusterd: add option to specify a different base-port

2013-11-06T11:06:40+00:00

This is (arguably) a hack to work around a bug in libvirt which is not
well behaved wrt to using TCP ports in the unreserved space between
49152-65535. (See RFC 6335)

Normally glusterd starts and binds to the first available port in range,
usually 49152. libvirt's live migration also tries to use ports in this
range, but has no fallback to use (an)other port(s) when the one it wants
is already in use.

libvirt cannot fix this in time for their impending release. This is
submitted to gerrit to provide some minimal visibility upstream to justify
hacking this change (as a temporary patch) into the glusterfs-3.4.1 RPMs
for Fedora 18-21 until libvirt can fix their implementation.

Change-Id: Ie77b00ac60730d1e48907dd0b38ddae92f3ac345
BUG: 987555
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/6147
Reviewed-by: Niels de Vos 
Tested-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Raghavan Pichai

store: move glusterd_store functions from mgmt/glusterd to libglusterfs

2013-07-04T04:27:45+00:00

        Backport of http://review.gluster.org/4676 and
                    http://review.gluster.org/5243

Making the glusterd_store_* functions re-usable will help with future
changes that need to read/write lists of items.

BUG: 904065
Change-Id: I99fb8eced76d12d5a254567eccff9790b43d8da3
Original-author: Niels de Vos 
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5279
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System

glusterd: Start bricks on glusterd startup, only once

2013-05-17T04:41:14+00:00

The restarting of bricks has been deffered until the cluster 'stabilizes'
itself volumes' view. Since glusterd_spawn_daemons is executed everytime
a peer 'joins' the cluster, it may inadvertently restart bricks that
were taken offline for say, maintenance purposes. This fix avoids that.

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

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

geo-rep / gsyncd: Separate log file directory for Mountbroker sessions

2013-02-05T01:34:56+00:00

... so that a mountbroker session which is initiated b/w master
and slave does not use the same log file if it's started after
a normal geo-rep session b/w master and slave. This results in
EPERM as the log file is owned by root and the geo-rep slave
process (now running as a non privileged user) does not have
access to it.

Also, having separate log file directory for mountbroker sessions
looks clean.

NOTE: geo-rep's client mount log file location remains unchanged.

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

glusterd/cli: Updated the options descriptions for "volume set help"

2013-01-22T07:03:57+00:00

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

core: fixes for gcc's '-pedantic' flag build

2013-01-22T06:17:36+00:00

* warnings on 'void *' arguments
* warnings on empty initializations
* warnings on empty array (array[0])

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

glusterd: replace obsolete /usr/local reference for remote ssh/gsyncd

2013-01-18T21:17:51+00:00

See https://bugzilla.redhat.com/show_bug.cgi?id=895656
    https://bugzilla.redhat.com/show_bug.cgi?id=764679 (GLUSTER-2947)
    https://bugzilla.redhat.com/show_bug.cgi?id=764623 (GLUSTER-2891)

The comments in the bzs are a bit obtuse and/or vague. As near as I
can make out we had, for a while, a "convenience symlink" to or from
/usr/local/libexec/gsyncd, which no longer exists.

And, lacking any comments in the code, I gather this is some sort of
fallback or failsafe logic: if the first, normal attempt to invoke gsyncd
fails then an attempt is made to ssh to the box and invoke it.

In any event, there's nothing in /usr/local/... so it's unquestionably
wrong to try to invoke anything there.

BUG: 895656
Change-Id: I3b7ac7a049b91ce101b930599294830147cc60ad
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/4392
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Joe Julian 
Reviewed-by: Anand Avati

glusterd: log enhancements for volume start

2013-01-04T15:26:25+00:00

* changed some of the log messages to give as much information as
  available in case of failure

* added logs to identify on which machine lock/stage/commit failed

* added macros to represent error strings to maintain uniformity
  among error messages for a given kind of error

* moved error logs wherever possible, from caller to callee to avoid
  code duplication

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

glusterd, cli: Task id's for async tasks

2012-12-19T21:32:49+00:00

This patch introduces task-id's for async tasks like rebalance, remove-brick and
replace-brick. An id is generated for each task when it is started and displayed
to the user in cli output. The status of running tasks is also included in the
output of "volume status" along with its id, so that a user can easily track the
progress of an async task.

Also,
 * added tests for this feature into the regression test suite.
 * added a python script for creating files, 'create-files.py', courtesy
   Vijaykumar Koppad (vkoppad@redhat.com) into the test suite.

This patch reverts the revert commit 698deb33d731df6de84da8ae8ee4045e1543a168.

BUG: 857330
Change-Id: Id43d7cb629a38f47f733fbc18cb4c5f2f0327c7a
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/4294
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati