glusterfs.git/xlators/mgmt/glusterd, branch v3.4.1qa2

glusterd: Calculate volume op-versions only on set/reset

2013-09-13T19:11:54+00:00

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

The volume op-versions are calculated during a volume set/reset, reading a
volume from disk and importing a volume during probe or volume sync. The
calculation of the volume op-version depends on the clusters op-version as some
features are enabled automatically depending on the clusters op-version. We
also don't store the volume op-versions persistently and don't export the
volume op-versions during sync. Due to this, there can occur cases which will
lead to inconsistencies in volumes in different peers. One such case is below,
Consider, a cluster made up 3 peers P1, P2 and P3, operating at op-version N.
The cluster has two volumes V1 and V2, which have volume op-versions N (since
volume op-version cannot be greater than cluster op-version). We have,
 Cluster-op-version = N
 V1 op-version = N
 V2 op-version = N
A set operation on V1 causes the clusters op-version to be bumped up to N+1.
Assume that there exist some features that are automatically enabled on
op-version N+1. The op-version of V2 remains at N as no operation has been
performed on it. So,
 Cluster op-version = N+1
 V1 op-version = N+1
 V2 op-version = N
Now, we probe a new peer P4. On the new peer we will have the following
op-versions,
 Cluster op-version = N+1
 V1 op-version = N+1
 V2 op-version = N+1
This happens because we don't send volume op-versions during the sync after
probe. P4 will freshly calculate the op-version of V2 (assuming features have
been auto enabled due to the cluster op-version being N+1) as N+1.
Another case is when glusterd on a peer restarts. Assume P3 was restarted,
glusterd will recalculate the volume op-versions during the restore state.
Again, op-version of V2 will be calculated as N+1 assuming auto enabled
features. This will lead to inconsistency in the volume representation in
memory and on disk, as glusterd will assume the volume contains auto enabled
features, but the volfiles don't contain them as they were not regenrated.
These kind of issues can be solved by calculating the volume op-version only
when features are enabled and disabled (ie. during volume set/reset),
persisting the volume-op-versions and exporting/importing them.

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

glusterd: Use volume op-versions during volgen

2013-09-13T19:11:35+00:00

  Backport of '3af61d6 glusterd: Use volume op-versions during volgen'
  from master

Instead of using the cluster op-version, volume op-version is used to
enable open-behind during volgen. For doing this, the volume op-versions
are updated before regenerating the volfiles.

BUG: 990830
Change-Id: I07e4a34004816c803fcbb3ee1ddd4b1e4c3a8006
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/5831
Reviewed-by: Krutika Dhananjay 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

mgmt/glusterd: Update sub_count on remove brick

2013-09-13T16:51:03+00:00

Change-Id: I7c17de39da03c6b2764790581e097936da406695
BUG: 1002556
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/5902
Tested-by: Gluster Build System

glusterd: Allow bumping down a peer's op-version during probe

2013-09-10T16:09:18+00:00

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

Earlier, a peer running a higher op-version couldn't be probed into a
cluster running at a lower op-version. This created issues when trying
to expand an upgraded cluster. This patch changes this behaviour.

The cluster no longer rejects a peer being probed if its op-version is
higher than the cluster op-version. The peer will reduce its op-version
if it doesn't have any volumes. If the peer contains volumes and needs
to reduce its op-version, it fails the handshake and the probe fails.

BUG: 1005038
Change-Id: Iabe790a9f826a4ac63d379eeeba01efcfef01f4d
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/5834
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: release big locks while doing mount

2013-09-10T08:21:14+00:00

Else things can deadlock in getspec v/s glusterd_do_mount()

Change-Id: Ie70b43916e495c1c8f93e4ed0836c2fb7b0e1f1d
BUG: 997576
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5881
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

performance/open-behind: use anonymous fd for doing fstat and readv

2013-09-10T00:19:36+00:00

Change-Id: I61a3c221e0a15736ab6315e2538c03dac27480a5
BUG: 846240
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4483
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5807
Reviewed-by: Kaleb KEITHLEY

glusterd: Give up biglock before brick's rpc unref

2013-08-14T08:14:15+00:00

This is to prevent the possibility of a deadlock when
rpc_connection_cleanup being called in the same thread as rpc_clnt_unref

Change-Id: Ia4dcc0a8a6e6158d4ddec68b780fccbc4cd64adb
BUG: 962619
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5326
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: Correct op-version of some options

2013-07-12T00:00:49+00:00

Some of the options have been backported to release-3.3 branch and hence
should have their op-version reduced. Some other options had op-version
incorrectly set as 1.

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

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: Disable transport before cleaning up rpc object

2013-06-19T04:53:27+00:00

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

Problem:
rpc_transport object, which is part of rpc_clnt, is destroyed
prematurely. This is because, rpc_transport object is ref'd by socket
layer and rpc layer. These ref's, until the synctask'izing of
operations, were unref'd sequentially in the epoll thread.
With more threads at play, the sequential unref guarantee is off.

Fix:
Shutting down the transport before proceeding with cleaning up of
rpc_clnt object would serialize the unref's on the rpc_transport object
and thus eliminating the race.

Also, we don't store the address of brickinfo in brick's rpc notify
function, to avoid the possibility of referring a freed brickinfo.
Instead we use a string based id to 'reach' the corresponding brickinfo.

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