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>

1 files changed, 26 insertions, 0 deletions

diff --git a/tests/geo-rep/georep-basic-dr-rsync.t b/tests/geo-rep/georep-basic-dr-rsync.t
index e8b39938082..39da524f639 100644
--- a/tests/geo-rep/georep-basic-dr-rsync.t
+++ b/tests/geo-rep/georep-basic-dr-rsync.t
@@ -119,6 +119,32 @@ TEST unlink_ok ${slave_mnt}/changelog_d2
 TEST data_ok ${slave_mnt}/changelog_f1 "HelloWorld!"                    #55
 TEST chown_file_ok ${slave_mnt}/changelog_chown_f1
 
+# logrotate test
+logrotate_simulate logrotate_test_file 2
+logrotate_simulate logrotate_test_file 2
+logrotate_simulate logrotate_test_file 2
+logrotate_simulate logrotate_test_file 2
+sleep 15
+EXPECT 0 check_status_num_rows "Faulty"
+
+# CREATE + RENAME
+create_rename create_rename_test_file
+sleep 15
+TEST $GEOREP_CLI $master $slave stop
+sleep 5
+TEST $GEOREP_CLI $master $slave start
+sleep 15
+TEST create_rename_ok create_rename_test_file                                #58
+
+# hard-link rename
+hardlink_rename hardlink_rename_test_file
+sleep 15
+TEST $GEOREP_CLI $master $slave stop
+sleep 5
+TEST $GEOREP_CLI $master $slave start
+sleep 15
+TEST hardlink_rename_ok hardlink_rename_test_file
+
 #Stop Geo-rep
 TEST $GEOREP_CLI $master $slave stop