glusterfs.git/xlators, branch v3.4.1

posix-acl: fixup extended ACL entries properly

2013-09-25T21:09:15+00:00

Typically when updating cached ACL from backend, we get both iatt and
ACL xattrs (like lookup, readdirplus etc.) However in calls like
setattr(), the mode would have updated but we receive only iatt and not
the ACL xattrs. In such case we need to "spread" the effects of the
changed mode properly into the cached ACL xattr ourselves.

Change-Id: I23a7bc9c14722ff6848e175ed4bbe863a21ce2c9
BUG: 998967
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/6002
Tested-by: Gluster Build System

gNFS: avoid double fd unref in opendir

2013-09-25T06:49:41+00:00

Noticed that the fd_unref was called on the fd regardless of the return
value at nfs3svc_opendir_readdir_cbk(), hence removing an extra unref in
the negative case in nfs_inode_opendir_cbk, which fixes the spurious
fd_unref().

Back port of: http://review.gluster.org/4943 (Rajesh Amaravathi)

Change-Id: Ibddf487c7890407d01befedd65eefb10cb9c989f
BUG: 1011761
Signed-off-by: Santosh Kumar Pradhan 
Reviewed-on: http://review.gluster.org/5996
Reviewed-by: Rajesh Joseph 
Tested-by: Gluster Build System

cluster/dht: Treat migration failures due to space constraints as skipped

2013-09-20T06:39:40+00:00

Currently rebalance/remove-brick op's display migration failed count even
for files which failed due to space issues (not enough space for file, or
migration leading to cluster imbalance)

These will now be counted as skipped, and rebalance/remove-brick status
will display the additional counter

BUG: 989846
Change-Id: I4efa7ce69dd43680ff47181afed0c561954c5080
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/5977
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

cli,glusterd: Task parameters in xml output

2013-09-19T21:08:02+00:00

 Backport of 91cd0eae2cc1d96cbafa6457835f146503355238 from master

This patch introduces task parameters for the asynchronus task shown in
volume status. The parameters are only given for xml output. The
parameters shown currently are,
- source and destination bricks for replace-brick tasks
  ......
        
          
            Replace brick
            3d1a1005-9d2e-4ae0-bd62-577bc1d333a3
            1
            
              archm:/export/test4
              archm:/export/test-replace1
            
          
        
  ......
- list of bricks being removed for remove-brick tasks
  ......
        
          
            Remove brick
            901c20ca-0da2-41de-8669-5f0caca6b846
            1
            
              archm:/export/test2
              archm:/export/test3
            
          
        
  ......

The changes for non-xml output will be done in a subsequent patch.

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

glusterd: Don't reset rebalance status on add-brick

2013-09-19T21:07:06+00:00

 Backport of 67c28b19355c47e96d1420405cc38753a3e5f9be from master

The rebalance status was being reset to 'Not started' when add-brick was
performed. This would lead to odd cases where a 'rebalance status' on a
volume would show status as 'not started' but would also include the
rebalance statistics. This also affected the showing of asynchronus task
status in 'volume status' command.

By not resetting the status prevent the above issues from happening.
Since we use the running/not-running of the rebalance process as the
check when performing other operations we can safely leave the rebalance
stats collected on an add-brick.

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

mount/fuse: Implement forget in cbks for fuse.

2013-09-19T21:05:30+00:00

With the introduction of inode_ctx_set in fuse as part of  2991503d014,
forget cbk gets called for fuse xlator. Though nothing needs to be done
inf forget_cbk, excessive log messages of the following kind are observed:

[2013-09-16 06:09:50.758063] W [defaults.c:1331:default_forget]
(-->/usr/local/lib/glusterfs/3git/xlator/mount/fuse.so(+0xa1f2) [0x7f51432781f2]
(-->/usr/local/lib/libglusterfs.so.0(inode_unref+0x3c) [0x7f5144e5
816c] (-->/usr/local/lib/libglusterfs.so.0(+0x2d061) [0x7f5144e58061]))) 0-fuse:
xlator does not implement forget_cbk

This patch prevents such log messages from being seen.
Signed-off-by: Vijay Bellur 
BUG: 979910
Change-Id: Ie5874138f46822b10ff4213bd1134d78330ec460
Reviewed-on: http://review.gluster.org/5932
Reviewed-by: Anand Avati 
Tested-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5975
Tested-by: Gluster Build System

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