glusterfs.git/tests, branch v3.5.2beta1

nfs: prevent assertion error with MOUNT over UDP

2014-07-10T07:15:18+00:00

The MOUNT service over UDP runs in a separate thread. This thread does
not have the correct *THIS xlator set. *THIS points to the global (base)
xlator structure, but GF_CALLOC() requires it to be the NFS-xlator so
that assertions can get validated correctly.

This is solved by passing the NFS-xlator to the pthread function, and
setting the *THIS pointer explicitly in the new thread.

It seems that on occasion (needs further investigation) MOUNT over UDP
does not unregister itself. There can also be issues when the kernel NLM
implementation has been registered at portmap/rpcbind, so adding some
unregister procedures in the cleanup of the test-cases.

Cherry picked from commit ec74ceedaa41047b88d270c00eeb071b73e19664:
> Change-Id: I3be5a420fc800bbcc14198d0b6faf4cf2c7300b1
> BUG: 1116503
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/8241
> Reviewed-by: Santosh Pradhan 
> Tested-by: Gluster Build System 
> Reviewed-by: Vijay Bellur 

Change-Id: I3be5a420fc800bbcc14198d0b6faf4cf2c7300b1
BUG: 1116997
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8258
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Santosh Pradhan

features/gfid-access: Fix entry operations

2014-07-08T08:13:15+00:00

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

Problem:
When more than one aux-mounts are performing rmdir .gfid//dir
simultaneously, then sometimes a hang is observed.  In gfid-access xlator When
virtual parent/inode are replaced with real parent/inode in loc, virtual
pargfid/gfid are not replaced with real pargfid/gfid respectively. Afr is using
parent_loc->gfids to order the entry locks. But parent_loc->gfid contains
random/virtual gfid generated by gfid-access xlator. Entrylk in client xlator
is using loc->inod->gfid for sending entrylk which has 'real' gfid. Because the
ordering is happening based on random gfids, One mount orders the locks as (L1,
L2) where as the other orders them as (L2, L1) leading to a dead-lock thus
a hang.

Fix:
Replace virtual pargfid/gfid with real pargfid/gfid when virtual-inodes are
replaced with real-inodes in loc.

BUG: 1114501
Change-Id: I13016de1da11762e0697792d76e6e946d991c0a4
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8251
Reviewed-by: Kotresh HR 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

features/gfid-access: Fix inode leaks and loc path corruption

2014-07-08T08:11:50+00:00

        Backport of http://review.gluster.org/8009
        Backport of http://review.gluster.org/8163

BUG: 1112659
Change-Id: Ic70a3ddfcfef88909c12ca6791a8e20c3fee2eae
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8250
Reviewed-by: Kotresh HR 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

tests: support regex in EXPECT constructs

2014-07-04T07:44:00+00:00

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

Instead of just strings, provide the ability to specify a regex
of the pattern to expect

Change-Id: I288db2290612accd795c3498f74e8b70bab21f2c
BUG: 1115369
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8235
Reviewed-by: Ravishankar N 
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System

gNFS: Support wildcard in RPC auth allow/reject

2014-07-02T11:28:21+00:00

RFE: Support wildcard in "nfs.rpc-auth-allow" and
"nfs.rpc-auth-reject". e.g.
  *.redhat.com
  192.168.1[1-5].*
  192.168.1[1-5].*, *.redhat.com, 192.168.21.9

  Along with wildcard, support for subnetwork or IP range e.g.
  192.168.10.23/24

The option will be validated for following categories:
1) Anonymous i.e. "*"
2) Wildcard pattern i.e. string containing any ('*', '?', '[')
3) IPv4 address
4) IPv6 address
5) FQDN
6) subnetwork or IPv4 range

Currently this does not support IPv6 subnetwork.

Cherry-picked from 00e247ee44067f2b3e7ca5f7e6dc2f7934c97181:
> Change-Id: Iac8caf5e490c8174d61111dad47fd547d4f67bf4
> BUG: 1086097
> Signed-off-by: Santosh Kumar Pradhan 
> Reviewed-on: http://review.gluster.org/7485
> Reviewed-by: Poornima G 
> Reviewed-by: Harshavardhana 
> Tested-by: Gluster Build System 
> Reviewed-by: Vijay Bellur 

Change-Id: I18ef0a914cd403c1f9e66d1b03ecd29465cbce95
BUG: 1115369
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/8223
Tested-by: Gluster Build System 
Reviewed-by: Santosh Pradhan

features/index : Creation of indices directory as soon as brick is up.

2014-06-27T08:48:49+00:00

Missing indices directory in the bricks leads to unwanted log messages.
Therefore, indices directory needs to be created as soon as the brick
comes up.
This patch results in creation of indices/xattrop directory as required.
Also includes a testcase to test the same.

Backport of http://review.gluster.org/#/c/6343/
and http://review.gluster.org/#/c/6426/

Change-Id: I2a6f48b78aa09357ed60e45b62ec5fb08f816d76
BUG: 1112111
Signed-off-by: Anuradha 
Reviewed-on: http://review.gluster.org/8152
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

cluster/stripe: Fix EINVAL errors on quota enabled volumes

2014-06-27T08:46:29+00:00

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

Write operations on directories with quota enabled used to fail with
EINVAL on stripe volumes. This was due to assert failure in
stripe_lookup(), meant to ensure loc->path is not NULL. However,
in nameless lookup (in this particular case triggered by quotad, which
has stripe xlator in its graph), loc->path can be legitimately NULL.

The fix involves removing this check in stripe_lookup().

Change-Id: Ibbd4f68763fdd8a85f29da78b3937cef1ee4fd1e
BUG: 1100050
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/8186
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Niels de Vos

cluster/stripe: don't treat ESTALE as failure in lookup

2014-06-24T16:57:54+00:00

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

Problem:
In a stripe volume, symlinks are created only on the first brick via the
default_symlink() call. During gfid lookup, server sends ESTALE from the other
bricks, which is treated as error in stripe_lookup_cbk()

Fix:
Don't treat ESTALE as error in stripe_lookup_cbk()

BUG: 1111454
Change-Id: I337ef847f007b7c20feb365da329c79c121d20c4
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/8153
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

cluster/afr: Fix resolution issues with afr

2014-06-24T16:26:13+00:00

Problem with afr:
Lets say there is a directory hierarchy a/b/c/d on the mount and the
user is cd'ed into the directory. Bring down one of the bricks of replica and
remove all directories/files to simulate disk replacement on that brick. Now
this brick is brought back up. Creates on the cd'ed directory fail with ESTALE.
Basically before sending a create of 'f' inside 'd', fuse sends a lookup to
make sure the file is not present.  On one of the bricks  'd' is present and
'f' is not so it sends ENOENT as response. On the new brick 'd' itself is not
present. So it sends ESTALE. In afr ESTALE is considered to be special errno on
witnessing which lookup has to fail. And ESTALE is given more priority than
ENOENT. Due to these reasons lookup fails with ESTALE rather than ENOENT. Since
lookup didn't fail with ENOENT, 'create' can't be issued so the command is
failed with ESTALE.

Solution:
Afr needs to consider ESTALE errno normally and ENOENT needs to
be given more priority so that operations like create can proceed even when
only one of the brick is up and running. Whenever client xlator identifies
that gfid-changed, it sets that information in lookup xdata. Afr uses this
information to fail the lookup with ESTALE so that top xlator can send
fresh lookup.

Change-Id: Ie8e0e327542fd644409eb5dadf451679afa1c0e5
BUG: 1112348
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/8154
Tested-by: Justin Clift 
Tested-by: Gluster Build System 
Reviewed-by: Ravishankar N 
Reviewed-by: Niels de Vos

features/index: Don't delete current xattrop index.

2014-06-24T09:27:55+00:00

Problem:
`gluster v heal  statistics heal-count` was not able to read the
number of entries to be healed from the source brick because the base xattrop
entries in indices/base_indices_holder and indices/xattrop were getting deleted
after a successful heal and the code flow prevented them from creating it again.

Fix:
Don't delete the xattrop index unless it is stale (i.e. brick is restarted)

Change-Id: Ief4eee0ddf42c4d8b711d00751be92bbbc7bbbb0
BUG: 1101647
Signed-off-by: Ravishankar N 
Reviewed-on: http://review.gluster.org/7897
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Niels de Vos