glusterfs.git/tests/bugs/quota/bug-1235182.t, branch v3.11dev

tests: Add mechanism for disabled tests

2016-03-10T07:19:40+00:00

Requirements:
Should be able to skip tests from run-tests.sh run.
Should be granular enough to disable on subset of OSes.

Solution:
Tests can have special comment lines with some comma separated values
within them.

Key names used to determine test status are
G_TESTDEF_TEST_STATUS_CENTOS6
G_TESTDEF_TEST_STATUS_NETBSD7
Some examples:
G_TESTDEF_TEST_STATUS_CENTOS6=BAD_TEST,BUG=123456
G_TESTDEF_TEST_STATUS_NETBSD7=KNOWN_ISSUE,BUG=4444444
G_TESTDEF_TEST_STATUS_CENTOS6=BAD_TEST,BUG=123456;555555
You can change status of test to enabled or delete the line only if all the
bugs are closed or modified or if the patch fixes it.

Change-Id: Idee21fecaa5837fd4bd06e613f5c07a024f7b0c2
BUG: 1295704
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/13393
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Kaushal M

tests/quota : improving tests for quota

2016-03-03T11:52:43+00:00

tests/basic/quota.t includes all the basic test that
needs to be tested for quota. In most of the other
tests specific to bugs(tests/bugs/quota/*), tests
such as creating and starting volume, enabling quota,
setting limit, writing data, doing list have been done
which is essential to write a individual quota test
file, but, if the specific bug just needs to test
*few* particular cases, I have moved those tests
under tests/basic itself to speedup the regressions.

Basics of inode-quota and it's enforcing, renaming
with quota are basic tests and is hence moved under
tests/basic folder.

In other files, I have removed tests which are not
needed, such as 'pidof glusterd' or checking for
'gluster volume info' or if there are any test which
is already being tested under tests/basic and is being
written again.

Change-Id: Iefd6d9529246d59829cc5bf02687a1861d8462a8
BUG: 1294826
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/13216
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Vijaikumar Mallikarjuna 
Reviewed-by: Jeff Darcy

quota: fix for spurious failure

2015-11-06T20:28:02+00:00

Filed a bug# 1278689.
For now marking the testcase tests/bugs/quota/bug-1235182.t' bad
once the bug# 1278689, remove the testcase from bad list

Change-Id: I224f907153d3e5f35834007a40b0050246d8787a
BUG: 1278689
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/12526
Tested-by: Gluster Build System 
Reviewed-by: Dan Lambright 
Tested-by: Dan Lambright

quota/marker: fix inode quota with rename

2015-08-19T17:43:54+00:00

There are three problems with marker-rename which
is fixed in this patch

Problem 1)
1) mq_reduce_parent_size is not handling inode-quota contribution
2) When dest files exists and IO is happening
   Now renaming will overwrite existing file
   mq_reduce_parent_size called on dest file
   with saved contribution, this can be
   a problem is IO is still happening
   contribution might have changed

Problem 2)
There is a small race between rename and in-progress write
Consider below scenario
1) rename FOP invoked on file 'x'
2) write is still in progress for file 'x'
3) rename takes a lock on old-parent
4) write-update txn blocked on old-parent to acquire lock
5) in rename_cbk, contri xattrs are removed and contribution is deleted and
   lock is released
6) now write-update txn gets the lock and updates the wrong parent
   as it was holding lock on old parent
   so validate parent once the lock is acquired

Problem 3)
when a rename operation is performed, a lock is
held on old parent. This lock is release before
unwinding the rename operation.
This can be a problem if there are in-progress
writes happening during rename, where update txn
can take a lock and update the old parent
as inode table is not updated with new parent

Change-Id: Ic3316097c001c33533f98592e8fcf234b1ee2aa2
BUG: 1240991
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11578
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

quota: Fix crash in quota enforcer

2015-07-14T11:04:03+00:00

With multiple hardlinks check_quota_limit is invoked for each parent
each of this check_limit can invoke validation
this can cause frame->local to get corrupted during validation.

Testcase tests/bugs/quota/bug-1235182.t fails spuriously with
this problem

Change-Id: I53adc54b431fb5f43e67a94248102ddaf0d7978f
BUG: 1238747
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11510
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

features/quota : Fix spurious failure

2015-07-13T04:34:53+00:00

Problem : Basically, in this test case a file is created
which exceeds the quota limit. Once the limit is reached
that file will be deleted. At the same moment we are
testing inode-quota. It can so happen that before the
marker updates the information related to deletion of
file, a new file creation operation comes and sees that
quota limit is still exceeded.

Solution : Inducing a check to see if marker updation
completed successfully.

Updated all the test case which has the similar
machanism and also moved the "usage" function
to a common place "volume.rc"

Change-Id: I36ddbc5ebbf1b74c9d326a0d1d5f3b32f20a906a
BUG: 1229297
Signed-off-by: Sachin Pandit 
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11125
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi

quota: marker accounting goes bad with rename while writing a file

2015-06-26T09:05:26+00:00

With below test-case, marker accounting becomes bad:
1) Create a volume with 1 brick
2) fuse mount
3) on one terminal write some data
   dd if=/dev/zero of=f1 bs=1M count=500 oflag=sync
4) on another terminal execute below rename operation while the write is
still in progress
    for i in {1..50}; do
        ii=`expr $i + 1`;
        mv f$i f$ii;
    done

remove-xattr is already on while doing rename operation,
we should not be doing again in background when reducing the
parent size

Change-Id: I969a64bb559e2341315928b55b99203e9ddee3f2
BUG: 1235195
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/11403
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
Tested-by: Gluster Build System 
Tested-by: Raghavendra G