| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* log rotate
eg. with rotate count as 2 and with the following files created
x.log, x.log.1 and x.log.2, another iteration of logrotate results in
the following operations to be performed
x.log.2 is renamed to x.log.3
x.log.1 is renamed to x.log.2
x.log is renamed to x.log.1
x.log.3 is deleted
x.log is created [possible gfid allocated that belonged to x.log.3]
when a file is created, there's a big possibility that a gfid used
earlier can be reassigned and reused. This causes RENAME operations
to fail on slave nodes when logs are replayed, typically on a Georep
restart.
A function called logrotate_simulate has been added to tests/geo-rep.rc
to help simulate this situation. Starting from a clean state,
logrotate_simulate has to be called 4 times with a rotate count of 2
to help the logs roll over and cause a delete at the end and a gfid
reallocation.
With the bug-fix in place, this test should not cause the Georep
session to go into a Faulty state.
* create+rename
On log replay after Georep restart, a create+rename causes an entry
to be created for the original file, but it cannot be linked to the
gfid back-end since it is associated with the renamed file before
the Georep restart.
A function create_rename simulates the create+rename scenario and
the function create_rename_ok tests if the dangling entry is present
at the slave mount.
With the bug-fix in place, a dangling entry with the original name
should not be found at the slave mount after logs are replayed after
a Georep restart.
* hard-link rename
This case is similar to the create+rename case except that this is
a case of renaming hard-link to one of its other names.
A function hardlink_rename has been added to tests/geo-rep.rc which
simulates the creation and rename of hard-link. After a Georep session
restart, the test function hardlink_rename_ok should not find the
source link name on the slave.
With the bug-fix in place, this test should not fail.
If changelogs have been enabled on the slave as well, then the logs
should show an UNLINK entry for the source link name, since a rename
operation of a hard link to one of its names essentially just drops
the source name as per the 'mv' command semantics.
Change-Id: I85b196c00cf79a11bada25ef2fe5f1dc5c0c858a
BUG: 1316389
Signed-off-by: Milind Changire <mchangir@redhat.com>
Reviewed-on: http://review.gluster.org/13663
Smoke: Gluster Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GEO-REP INTEROP WITH SHARD FEATURE
Problem:
The sequence of entry creation and chown in master
is recorded as creation of entry with resulted
user:group in xsync changelog. During sync, entry
creation is always split into two ops, MKNOD and
SETATTR. Hence the issue is not being hit otherwise
it would have failed with EPERM if parent is owned
by different user. But with shard translator being
enabled on slave, doing entry creation with MKNOD and
SETATTR is not allowed, SETATTR fails as it accesses
inode structure which is not linked.
Solution:
The sequence of entry creation and chown in master
should be recorded as MKNOD and SETATTR separately always
and do entry creation with single op in gfid-access
xlator. The gfid-access patch will be sent separately.
Change-Id: I93e554bf9342397a7660503f5128e9709f8a0cd8
BUG: 1265148
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/12205
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the function 'data_tests' and TEST
each fop in testcase itself to determine
the exact test that fails.
Change-Id: Iffc3e2ac3b0fc0c7c64259fcdff8f27b146dcb9b
BUG: 1227624
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/11907
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
|
|
This is a new simple regression test suite for
geo-replication. This is written keeping in mind
the run time for regression test. The existing
regression test suite is rigorous one and could
be run nightly. Hence the existing geo-rep tests
are being removed as part of this.
Also re-enable geo-rep regression with this patch.
Thanks Aravinda for initial template and plan.
Change-Id: If544ac295eaf67ac66e0b071903cc1096e71d437
BUG: 1227624
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/11058
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
|