geo-rep: create hardlink as hardlinks in xsync crawl

BUG: 847839
Change-Id: Ieaa754f15611392c09afcc7190b9ff9da39d7fce
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Reviewed-on: http://review.gluster.org/5934
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
geo-replication: treat MKNOD also as regular file create

Change-Id: Iec04f642282b554a4d1b5f5c8cdc099fd001b3f4
Original-Author: Venky Shankar <vshankar@redhat.com>
Signed-off-by: Amar Tumballi <amarts@redhat.com>
BUG: 847839
Reviewed-on: http://review.gluster.org/5949
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
geo-rep: pack the value of 'readlink()' while crawling symlinks

without having 'readlink()' value, symlink fails on slave mounts

Change-Id: Ib84be8db77c033029ba8ba454fd629a496fc3fe1
Signed-off-by: Amar Tumballi <amarts@redhat.com>
BUG: 847839
Reviewed-on: http://review.gluster.org/5950
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
glusterd: Adding transaction checks for cluster unlock.

While a gluster command holding lock is in execution,
any other gluster command which tries to run will fail to
acquire the lock. As a result command#2 will follow the
cleanup code flow, which also includes unlocking the held
locks. As both the commands are run from the same node,
command#2 will end up releasing the locks held by command#1
even before command#1 reaches completion.

Now we call the unlock routine in the code path, of the cluster
has been locked during the same transaction.
Signed-off-by: Avra Sengupta <asengupt@redhat.com>

Change-Id: I7b7aa4d4c7e565e982b75b8ed1e550fca528c834
BUG: 1008172
Signed-off-by: Avra Sengupta <asengupt@redhat.com>
Reviewed-on: http://review.gluster.org/5937
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-by: Anand Avati <avati@redhat.com>
glusterd.service (systemd), ensure glusterd starts before local mounts

NOTICE: this patch was accepted onto the release-3.4 branch for 3.4.1,
but this same patch for master is languishing here in review.

Try (emphasis on the try) to ensure that glusterd starts, and in turn
starts glusterfsd before init attempt to mount any gluster (or gluster
NFS) volumes in /etc/fstab.

N.B. Joe Julian says this doesn't fix the problem for him, although it
worked for me in kvm. Lennart Poettering says it should, and we should
file a BZ against systemd if it doesn't. See
https://lists.fedoraproject.org/pipermail/devel/2013-July/185870.html

Change-Id: I4d8061217d8301beb0da485dc63a1984a7c57c37
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
BUG: 1004795
Reviewed-on: http://review.gluster.org/5823
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>