glusterfs.git/xlators, 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

cluster/dht: Ignore subvols with error in min-free-disk/inodes

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

Currently when selecting a alternative subvolume when hashed
subvol has exceeded min-free-disk/inodes, we do not check if
layouts have errors (including decommissioning). This leads
to data being written to those subvolumes, and in case of
decommissioning, will lead to data loss.

BUG: 982919

> Original-Author: shishir gowda 
> Reviewed-on: http://review.gluster.org/5299

Change-Id: If301a86cf3ca5fad6529bd2e61382f9901663ba0
Signed-off-by: Amar Tumballi 
Reviewed-on: http://review.gluster.org/5888
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

performance/write-behind: invoke request queue processing if

2013-09-10T08:22:49+00:00

we find fd marked bad while trying to fulfill lies.

* flush was queued behind some unfulfilled write.
* A previously wound write returned an error and hence fd was marked
  bad with corresponding error.
* wb_fulfill_head (invocation probably rooted in wb_flush), before
  winding checks for failures of previous writes and since there was a
  failure, calls wb_head_done without even winding one request in head.
* wb_head_done unrefs all the requests in list "head".
* since flush was last operation on fd (and most likely last operation
  on inode itself), no one invokes wb_process_queue and flush is stuck
  in request queue for eternity.

Change-Id: I3b5b114a1c401d477dd7ff64fb6119b43fda2d18
BUG: 988642
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/5883
Tested-by: Gluster Build System

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

mount/fuse: save the basefd flags in the new fd

2013-09-10T08:20:58+00:00

Upon graph switch, the basefd's flags were not saved in the new fd created
for the new graph upon which all the further requests for the open file
would come. Thus posix was treating the fd as a read-only fd and was
denying the write on the fds.

Change-Id: I781b62b376a85d1a938c091559270c3f242f1a2a
BUG: 998352
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/5880
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

io-cache: fix unsafe typcasting of pointer to uint64

2013-09-10T08:20:45+00:00

The typecast of pointer to uint64_t *, followed by setting of
64bit in inode_ctx_get() results in memory corruption on 32bit
system.

Change-Id: I32fa3bf3b853ed2690a9b9a471099a59b9d7186a
BUG: 997902
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5879
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

cluster/afr: unlock before aborting transaction

2013-09-10T08:20:26+00:00

Else this results in a missing frame causing a hang

Change-Id: Ib5f3dc6a3999449faa2853cee2944af2fb065a20
BUG: 1002399
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5878
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur