glusterfs.git/tests/bugs, branch testing-regression-job

tests/bug-844688.t: test bug-844688.t is failing on master

2019-03-13T11:58:20+00:00

Test case bug-844688.t is failing quite frequently on master.
This test check for the existence of call_stack, frame creation
time.

But there is a chance that at a point in time, the stack count
might become zero. So doing the check in EXPECT_WITHIN make
more sense.

Change-Id: Id2ede7f6fdcb5f016f52c5c0557ce6ac510d4e96
updates: bz#1688116
Signed-off-by: Mohammed Rafi KC

test: Fix a missing a '$' symbol

2019-03-13T07:37:25+00:00

While checking a test case using EXPECT_WITHIN, the
argument is actually missing a '$' symbol to denote
the token as a variable in bash

Change-Id: I5b9150acdea000b29e94cfb01d975c77f5ece3e5
fixes: bz#1688116
Signed-off-by: Mohammed Rafi KC

cluster/afr: Send truncate on arbiter brick from SHD

2019-03-11T11:21:00+00:00

Problem:
In an arbiter volume configuration SHD will not send any writes onto the arbiter
brick even if there is data pending marker for the arbiter brick. If we have a
arbiter setup on the geo-rep master and there are data pending markers for the files
on arbiter brick, SHD will not mark any data changelog during healing. While syncing
the data from master to slave, if the arbiter-brick is considered as ACTIVE, then
there is a chance that slave will miss out some data. If the arbiter brick is being
newly added or replaced there is a chance of slave missing all the data during sync.

Fix:
If there is data pending marker for the arbiter brick, send truncate on the arbiter
brick during heal, so that it will record truncate as the data transaction in changelog.

Change-Id: I3242ba6cea6da495c418ef860d9c3359c5459dec
fixes: bz#1686568
Signed-off-by: karthik-us

tests/dht: Remove hardcoded brick paths

2019-02-18T04:44:22+00:00

The tests assumed that the file is created on a
particular brick.This need not be the case
in all scenarios and has been removed.

Change-Id: Id420f43d7f72d983a7c6f16ea8fed273d46c4824
updates: bz#1672480
Signed-off-by: N Balachandran

tests/dht: Stop volume before unmounting bricks

2019-02-13T14:14:08+00:00

The bricks are loopback devices. Unmounting them is done
before the cleanup and leads to "target is busy" messages.

Change-Id: Ia808c2c9580273e1bf0595ecf53c210847c44577
fixes: bz#1676736
Signed-off-by: N Balachandran

Bump up timeout for tests on AWS

2019-02-07T03:30:55+00:00

Fixes: bz#1672727
Change-Id: I2b9be45f199f6436b858536c6f49be85902217f0
Signed-off-by: Nigel Babu

glusterd: manage upgrade to current master

2019-02-04T03:47:15+00:00

Scenarios tested:

* Upgrade the node when there are stripe / tiering and regular
type of volumes are present.
  - All volumes are started fine (as the change was not on brick volfile)
  - For tier, the functionality may not even work, as changetimerecorder
    is not present.
  - 'gluster volume info' properly shows as 'NOT SUPPORTED' for stripe and
    tier type of volume.

* Upgrade in a rolling upgrade scenario, where an old version is
able to connect to higher master.
  - on a normal volume, if the volfile-server was new, the newer client
    volfiles needed to have utime xlator conditionally.
  - with this one change, all other changes seem to work fine.

Change-Id: Ib2d3b69dafa02b2c695a735b13c1aa70aba07cb8
updates: bz#1635688
Signed-off-by: Amar Tumballi

readdir-ahead: do not zero-out iatt in fop cbk

2019-01-31T06:18:14+00:00

...when ctime is zero. ia_type and ia_gfid always need to be non-zero
for things to work correctly.

Problem:
Commit c9bde3021202f1d5c5a2d19ac05a510fc1f788ac zeroed out the iatt
buffer in the cbks of modification fops before unwinding if the ctime in
the buffer was zero. This was causing the fops to fail: noticeable when
AFR's 'consistent-metadata' option was enabled. (AFR zeros out the ctime
when the option is set. See commit
4c4624c9bad2edf27128cb122c64f15d7d63bbc8).

Fixes:
-Do not zero out the ia_type and ia_gfid of the iatt buff under any
circumstance.
-Also, fixed _rda_inode_ctx_update_iatts() to always update these values from
the incoming buf when ctime is zero. Otherwise we end up with zero
ia_type and ia_gfid the first time the function is called *and* the
incoming buf has ctime set to zero.

fixes: bz#1670253
Reported-By:Michael Hanselmann 
Change-Id: Ib72228892d42c3513c19fc6dfb543f2aa3489eca
Signed-off-by: Ravishankar N

features/shard: Ref shard inode while adding to fsync list

2019-01-24T18:14:57+00:00

PROBLEM:

Lot of the earlier changes in the management of shards in lru, fsync
lists assumed that if a given shard exists in fsync list, it must be
part of lru list as well. This was found to be not true.

Consider this - a file is FALLOCATE'd to a size which would make the
number of participant shards to be greater than the lru list size.
In this case, some of the resolved shards that are to participate in
this fop will be evicted from lru list to give way to the rest of the
shards. And once FALLOCATE completes, these shards are added to fsync
list but without a ref. After the fop completes, these shard inodes
are unref'd and destroyed while their inode ctxs are still part of
fsync list. Now when an FSYNC is called on the base file and the
fsync-list traversed, the client crashes due to illegal memory access.

FIX:

Hold a ref on the shard inode when adding to fsync list as well.
And unref under following conditions:
1. when the shard is evicted from lru list
2. when the base file is fsync'd
3. when the shards are deleted.

Change-Id: Iab460667d091b8388322f59b6cb27ce69299b1b2
fixes: bz#1669077
Signed-off-by: Krutika Dhananjay

tests: run nfs tests only if --enable-gnfs is provided

2019-01-24T15:18:00+00:00

Fixes: bz#1665358
Change-Id: Idbf88ec3ac683733b32c313377eeb72f2819bf0d
Signed-off-by: Amar Tumballi