summaryrefslogtreecommitdiffstats
path: root/tests/geo-rep.rc
diff options
context:
space:
mode:
authorMilind Changire <mchangir@redhat.com>2016-03-10 13:45:52 +0530
committerAravinda VK <avishwan@redhat.com>2016-08-09 00:29:35 -0700
commit76401324af5a5e7dc3acf8d4fbe4884d6c3f0281 (patch)
tree07dc12791e24a56b1e9af3f2d5a8491c4b72c098 /tests/geo-rep.rc
parent949472d7561d3bfd67d8204e433a25dbc8a596cc (diff)
georep: tests for logrotate, create+rename, hard-link rename
* 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>
Diffstat (limited to 'tests/geo-rep.rc')
-rw-r--r--tests/geo-rep.rc70
1 files changed, 70 insertions, 0 deletions
diff --git a/tests/geo-rep.rc b/tests/geo-rep.rc
index e811f9a5b76..1a44b4a3941 100644
--- a/tests/geo-rep.rc
+++ b/tests/geo-rep.rc
@@ -160,3 +160,73 @@ function create_georep_session()
rc=$?
if test $rc != 0; then return $rc; fi
}
+
+# logrotate_simulate should be called (rotate_count + 1) times to cause
+# an unlink and a gfid re-allocation.
+# remember to keep the file name and rotate_count the same across the
+# calls
+function logrotate_simulate()
+{
+ file_name=$1
+ declare -i rotate_count=$2
+
+ while [ $rotate_count -ge 0 ]; do
+ source_file="${master_mnt}/$file_name.$((rotate_count))"
+ if [ $rotate_count -eq 0 ]; then
+ source_file="${master_mnt}/$file_name"
+ fi
+ if [ -f "${source_file}" ]; then
+ mv "${source_file}" "${master_mnt}/$file_name.$((rotate_count+1))"
+ fi
+ ((rotate_count--))
+ done
+
+ # logrotate causes gfid to be rellocated to a new file created
+ # after an unlink and a blind rename later causes georep session
+ # to go Faulty
+ # this should not happen if source basename on slave is tested
+ # to be linked with its own gfid as on master, before invoking
+ # the rename syscall
+ touch ${master_mnt}/$file_name
+ rotate_count=$2
+ unlink_file_name="${master_mnt}/$file_name.$((rotate_count+1))"
+ unlink $unlink_file_name
+}
+
+function create_rename()
+{
+ file_name=$1
+ echo $file_name > ${master_mnt}/$file_name
+ mv ${master_mnt}/$file_name ${master_mnt}/$file_name.bak
+}
+
+function create_rename_ok()
+{
+ file_name=$1
+ # after a log replay, we don't expect the original file
+ # to be recreated i.e. a dangling entry without a corresponding
+ # back-end gfid link should not exist on the slave
+ if [ -f "${slave_mnt}/$file_name" ]; then
+ return 1
+ fi
+ return 0
+}
+
+function hardlink_rename()
+{
+ file_name=$1
+ echo $file_name > ${master_mnt}/$file_name
+ ln ${master_mnt}/$file_name ${master_mnt}/$file_name.hl
+ mv ${master_mnt}/$file_name.hl ${master_mnt}/$file_name
+}
+
+function hardlink_rename_ok()
+{
+ file_name=$1
+ # the hardlink file should not exist on the slave after renaming
+ # to one of its links
+ if [ -f "${slave_mnt}/$file_name.hl" ]; then
+ return 1
+ fi
+ return 0
+}