glusterfs.git/xlators/mgmt/glusterd/src/glusterd-utils.c, branch v3.6.3

glusterd: don't start gluster-nfs when NFS is disabled

2015-03-25T08:54:07+00:00

Backport of http://review.gluster.org/9835

Change-Id: Iff9c8e8d2233048f3e5c9ee8b5af38ba10193cb9
BUG: 1199936
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/9843
Reviewed-by: Atin Mukherjee 
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

glusterd: Maintain per transaction xaction_peers list in syncop & mgmt_v3

2015-02-26T12:00:32+00:00

In current implementation xaction_peers list is maintained in a global variable
(glustrd_priv_t) for syncop/mgmt_v3. This means consistency and atomicity of
peerinfo list across transactions is not guranteed when multiple syncop/mgmt_v3
transaction are going through.

We had got into a problem in mgmt_v3-locks.t which was failing spuriously, the
reason for that was two volume set operations (in two different volume) was
going through simultaneouly and both of these transaction were manipulating the
same xaction_peers structure which lead to a corrupted list. Because of which in
some cases unlock request to peer was never triggered and we end up with having
stale locks.

Solution is to maintain a per transaction local xaction_peers list for every
syncop.

Please note I've identified this problem in op-sm area as well and a separate
patch will be attempted to fix it.

Finally thanks to Krishnan Parthasarathi and Kaushal M for your constant help to
get to the root cause.

Backport URL : http://review.gluster.org/#/c/9269/
               http://review.gluster.org/#/c/9422/
               http://review.gluster.org/#/c/9350/
    
Change-Id: Ib1eaac9e5c8fc319f4e7f8d2ad965bc1357a7c63
BUG: 1176756
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/9269
Tested-by: Gluster Build System 
Reviewed-by: Kaushal M 
Reviewed-on: http://review.gluster.org/9328
Reviewed-by: Raghavendra Bhat 
Tested-by: Raghavendra Bhat

glusterd: Fix spurious volume delete failure

2015-02-11T11:45:36+00:00

If volume uses quota, volume delete operation should unmount the
auxiliary quota mount usin glusterd_remove_auxiliary_mount(). This
may fail with EBADF is the mount is already gone. In that situation,
ignore the error so that volume delete succeeds.

This fixes a spurious failure on NetBSD in tests/basic/quota.t 74-75

Backport of I69325f71fc2c8af254db46f696c8669a4e6bd7e4

BUG: 1138897
Change-Id: If0d382d44a956bb9fd8c41299f82affdf2ee0618
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/9484
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Krishnan Parthasarathi

mgmt/glusterd: do not restart nfs server when snapshot is deactivated

2015-01-09T09:35:02+00:00

> Change-Id: Ie5eaa2beb4446640b22873f91e17da90d1cd8fad
> BUG: 1174625
> Signed-off-by: Raghavendra Bhat 
> Reviewed-on: http://review.gluster.org/9280
> Tested-by: Gluster Build System 
> Reviewed-by: Kaushal M 
> Signed-off-by: Raghavendra Bhat 

Change-Id: Ic5049f919fb444b45b3372a3b486183ed46d60f8
BUG: 1180404
Reviewed-on: http://review.gluster.org/9425
Tested-by: Gluster Build System 
Reviewed-by: Kaushal M 
Reviewed-by: Raghavendra Bhat

glusterd/uss: Create rebalance volfile.

2015-01-08T09:14:43+00:00

Create a new rebalance volfile, which will not contain
snap-view client translators, irrespective of the status
of USS.

This volfile, will be created and regenerated everytime
the fuse-volfile is generated, and will be consumed
by the rebalance process.

Change-Id: I514a8e88d06c0b8fb6949c3a3e6dc4dbe55e38af
BUG: 1175758
Signed-off-by: Avra Sengupta 
Reviewed-on: http://review.gluster.org/9190
Tested-by: Gluster Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Krishnan Parthasarathi 
Signed-off-by: Sachin Pandit 
Reviewed-on: http://review.gluster.org/9339
Reviewed-by: Raghavendra Bhat

glusterd/uss: if snapd is not running, return success from glusterd_handle_snapd_option.

2015-01-08T09:14:01+00:00

glusterd_handle_snapd_option was returning failure if snapd is not running
because of which gluster commands were failing.

Change-Id: I22286f4ecf28b57dfb6fb8ceb52ca8bdc66aec5d
BUG: 1175765
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/9206
Reviewed-by: Kaushal M 
Reviewed-by: Avra Sengupta 
Tested-by: Gluster Build System 
Reviewed-by: Vijaikumar Mallikarjuna 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Krishnan Parthasarathi 
Signed-off-by: Sachin Pandit 
Reviewed-on: http://review.gluster.org/9311
Reviewed-by: Raghavendra Bhat

rdma: Client volfile name change for supporting rdma

2015-01-06T09:55:38+00:00

        Backport of http://review.gluster.org/9146

For rdma only volumes, daemons like snapd, glustershd etc make
use of tcp transport for their operations. This patch will introduce
the support of rdma by default for those daemons in rdma only volumes.
In order to accomodate this change we rename the tcp client volfile
labels from

-fuse.vol
to
.tcp-fuse.vol

Change-Id: Id5e5db0680a07fa6b6d003bad45748464cd7658e
BUG: 1166515
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/9146
Tested-by: Gluster Build System 
Reviewed-by: Kaushal M 
Reviewed-on: http://review.gluster.org/9183
Reviewed-by: Raghavendra G 
Reviewed-by: Raghavendra Bhat

rdma: Wrong volfile fetch on fuse mounting tcp,rdma volume via rdma

2015-01-06T09:53:56+00:00

        Backport of http://review.gluster.org/8498

As of now for both tcp only volumes and rdma only volumes, volfile
names are in the format -fuse.vol. This patch will change
the client volfile namings as shown below.

 * TCP mounts always use -fuse.vol
 * RDMA mounts always use .rdma-fuse.vol

Following the above naming convention, for tcp,rdma volumes both
volfiles will be present under /var/lib/glusterd/vols//
such that rdma only volume can be mounted as

mount -t glusterfs -o transport=rdma :/ 
OR
mount -t glusterfs :/.rdma 

The above command format can also be used to fuse mount a tcp,rdma
volume via rdma transport.

When we try to fuse mount a tcp,rdma volume with transport-type as rdma
it silently mounts via tcp. This change will also make sure that it
fetches the correct volfile based on the transport-type specified
from client side.

Change-Id: Id8b74c1c3e1e7fd323463061f8b13dd623fa6876
BUG: 1166515
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/8498
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9182
Reviewed-by: Raghavendra Bhat

rdma: client connection establishment takes more time

2015-01-06T09:43:45+00:00

        Backport of http://review.gluster.org/8934

For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: I82a8a27f0e65a2e287f321e5e8292d86c6baf5b4
BUG: 1166515
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9177
Reviewed-by: Raghavendra Bhat

rdma :mount fails for nfs protocol in rdma volumes

2015-01-06T09:32:32+00:00

When we mount rdma only volume or tcp,rdma volume using newly
peer probed IP's(nfs-server on new nodes) through nfs protocol,
mount fails for rdma only volume and mount happens with
help of tcp protocol in the case of tcp,rdma volumes. That is for
newly added servers will always get transport type as "socket".
This is due to nfs_transport_type is exported correctly and
imported wrongly.

This can be verified by the following ,
   * Create a rdma only volume or tcp,rdma volume
   * Add a new server into the trusted pool.
   * Checkout the client transport type specified nfs-server
     volgraph.It will be always tcp(socket type) instead of rdma.
   * And also for rdma only volume in the nfs log, we can see
     'connection refused' message for every reconnect between
     nfs server and glusterfsd.

Backport of http://review.gluster.org/8975
cherry picked from commit f380e2029d608f97e3ba9a728605e1d798b09e8d

>BUG: 1157381
>Change-Id: I6bd4979e31adfc72af92c1da06a332557b6289e2
>Author:    Jiffin Tony Thottan 
>Signed-off-by: Jiffin Tony Thottan 
>Reviewed-on: http://review.gluster.org/8975
>Reviewed-by: Meghana M 
>Reviewed-by: Atin Mukherjee 
>Reviewed-by: Niels de Vos 
>Tested-by: Niels de Vos 

Change-Id: I328c17b07e877fe3b29ca832bf6f2291cea16bbe
BUG: 1166505
Reviewed-on: http://review.gluster.org/9172
Tested-by: Gluster Build System 
Reviewed-by: soumya k 
Reviewed-by: Raghavendra Bhat