[Bugs] [Bug 1316389] georep: tests for logrotate, create+rename and hard-link rename

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1316389



--- Comment #4 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/13663 committed in master by Aravinda VK
(avishwan at redhat.com) 
------
commit 76401324af5a5e7dc3acf8d4fbe4884d6c3f0281
Author: Milind Changire <mchangir at redhat.com>
Date:   Thu Mar 10 13:45:52 2016 +0530

    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 at redhat.com>
    Reviewed-on: http://review.gluster.org/13663
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    Reviewed-by: Aravinda VK <avishwan at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7WuHpnDFOc&a=cc_unsubscribe