glusterd: Expect setmntent(3) to return NULL

- Closed the mtab FILE * using endmntent(3)

Change-Id: I5e1ebb7f092abda638cfbb5524da693dcac6c872
BUG: 851109
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/3920
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Reviewed-by: Anand Avati <avati@redhat.com>
Detect python > 2.5, make sure MKDIR_P is substituted

gluster build machine generate configure scripts unable to detect python > 2.5
This change include a more recent python.m4 so that newer python can be
correctly detected.

Build.gluster.com also produces a configure that fails to subsitute
MKDIR_P, leading to bugs at make install. Works this around by
introducing mkdirp.m4 from aclocal-1.11, with the autoconf version test
removed because build.gluster.com also has an outdated autoconf. And
we need a bit from a recent autoconf

NB: this patchset changes nothing since the last one, I just fix title
in gerrit.

BUG: 764655
Change-Id: I3ffac50cc7a10cb9e56dd490dbc2b550bba3fabd
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/3888
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>
cli: Added special key "group" for bulk volume set.

gluster volume set VOLNAME group group_name

- where group_name is a file under /var/lib/glusterd/groups containing one
  key, value pair per line as below,
  key1=value1
  key2=value2
  [...]
- the command sets key1 to value1 and so on.

Change-Id: Ic4c8dedb98d013b29a74e57f8ee7c1d3573137d2
BUG: 851237
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/3831
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Reviewed-by: Anand Avati <avati@redhat.com>
event: peel out poll and epoll specific code into separate files

code re-org, no change in logic.

Change-Id: Ib1cb3d3f4cf8989a916df7476479c26570d07a84
BUG: 821087
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/3932
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
dht: improve dht_fix_layout_of_directory for better re-assignment

Jeff Darcy wrote:
> AFAICT, the fix-layout code doesn't do the same rotation that the
> new-directory code does. Therefore, the new bricks always claim
> completely predictable hash ranges for every directory, leading to
> either a 0-1-2-3 pattern or a 1-0-2-3 pattern.  In other words, a
> file whose hash falls into the second quarter of the range will always
> be assigned to brick 2, and a file whose hash falls into the fourth
> quarter will always be assigned to brick 3.  The rest will be split
> according to the original pattern.  Put still another way, instead of
> same-named files in different directories being spread across N bricks,
> they might be spread across only two bricks (bad) or totally
> concentrated on one brick (worse) regardless of N.

The current dht_fix_layout_of_directory() code, in an attempt to
maximize overlap of new layout with existing layout (to minimize
movement of data) fails to do a good job of randomizing new assignment
even when it could do a better job. In an example where we expand
from 2 nodes to 4 nodes, the current possibilities are limited in the
following way -

(theoretical hash range: 00 - 99)

OLD 1
-----
server1: 00 - 49
server2: 50 - 99

NEW 1
-----
server1: 00 - 24
server2: 50 - 74
server3: 25 - 49
server4: 75 - 99

OLD 2
-----
server1: 50 - 99
server2: 00 - 49

NEW 2
------
server1: 50 - 74
server2: 00 - 24
server3: 25 - 49
server4: 75 - 99

The above shows that when add-brick from 2 bricks to 4 bricks, server3
and server4 always get the _same_ hash range no matter what the original
hash range assignment was.

The fix in this patch is first do the standard new directory assignment
to a directory (with rotation etc.) and then do the reassignment to
maximize overlap. This way newly added servers still get random ranges
and existing servers have a probability of getting either of the quarters
which were part of its half previously. The same principles hold for
all add-brick from M to M+N.

Change-Id: I0cbbf3bfa334645728072d66aaaa80120d0b295f
BUG: 853258
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/3883
Tested-by: Gluster Build System <jenkins@build.gluster.com>
fuse-bridge: Pass unknown option down to fuse

In Linux, certain "filesystem-specific" options (passed in string form in last
argument to mount(2)), such as "rootcontext" or "context" are in fact common to
all filesystems, including fuse. We should pass them down to the actual
mount(2) call untouched.

This is achieved by adding "fuse-mountopts" option to mount/fuse translator and
adjusting the mount helper to propagate it with unrecognized options as they
are encountered.

BUG: 852754
Change-Id: I309203090c02025334561be235864d8d04e4159b
Signed-off-by: Lubomir Rintel <lubo.rintel@gooddata.com>
Reviewed-on: http://review.gluster.org/3871
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>
geo-rep / gsyncd: gsyncd binary wrapper context fixes

Changes to __gf_calloc (commit ed4b76ba) triggers a recursive
sequence of _gf_log() and __glusterfs_this_location() calls. This
is due to __gf_calloc() trying to access THIS which is not valid
in the context of geo replication binary wrapper. This patch fixes
the problem by introducing the relevant context in the wrapper.

Change-Id: I32b0b6927074692dbf66bad2f3e93434201aaa82
BUG: 849304
Signed-off-by: Venky Shankar <vshankar@redhat.com>
geo-rep: implement vectored xtime properly with backward compatibility

- implement versioning for RePCe protocol and service:
  client asks for server version, calculates highest
  common supported version, and instructs server to
  switch to that version
- for the server object, specify three versions:
  1.00: original, unary xtimes
  1.01: "dictered" multi-xtime (xtimes exchanged in uuid:time dict)
  1.02: vectored xtime (xtimes exchanged in list, where list position
        determines association)
  (due to lack of versioning so far, 1.01 is reported over the wire
  as 1.00, so we use some heuristics to discover if server is in
  fact 1.01)
- For master, port over the whole code to vectored xtime (thus breaking
  the coupling of sync modes and xtime flavors). The xtime related
  routines were moved back to the base class, and the mode mixins
  became much leaner (expressing only the differences in the sync
  logic). This is accomplished by creating wrappers that
  implement the 1.02 interface for slaves with version < 1.02.

Change-Id: I3369391a0825867fd47e38d33cae6c3ff875cb95