REVIEW: http://review.gluster.org/12762 (tier/ctr: Correcting rename logic) posted (#1) for review on release-3.7 by Joseph Fernandes
COMMIT: http://review.gluster.org/12762 committed in release-3.7 by Dan Lambright (dlambrig) ------ commit aa775565bf7302d98da66e49ed063aab1698b282 Author: Joseph Fernandes <josferna> Date: Sat Nov 21 01:04:21 2015 +0530 tier/ctr: Correcting rename logic Problem: When a file with old_file_name and GFID_1 is renamed with a new_file_name which already exists and with GFID_2, this is what happens in linux internaly. a. "new_file_name" is unlinked for GFID_2 b. a hardlink "new_file_name" is created to GFID_1 c. "old_file_name" hardlink is unlinked for GFID_2. Well this is all internal to linux, and gluster just issues a rename system call at POSIX layer. But CTR Xlator doesn't delete the entries corresponding to the "new_file_name" and GFID_2. Thus leaving the stale entry in the DB. The following are the implications. a. Promotion are tried on these stale entries which will fail and show false results in the status of migration, b. GFID_2 Files with 2 hardlinks, which will have only one hardlink after the rename will not be promoted or demoted as the DB shows 2 entries. Solution: Delete the older database entry for the replaced hardlink Backport of http://review.gluster.org/12711 > Change-Id: I4eafa0872253e29ff1f0bec4283bcfc579ecf0e2 > BUG: 1284090 > Signed-off-by: Joseph Fernandes <josferna> > Reviewed-on: http://review.gluster.org/12711 > Tested-by: NetBSD Build System <jenkins.org> > Tested-by: Gluster Build System <jenkins.com> > Reviewed-by: Dan Lambright <dlambrig> > Tested-by: Dan Lambright <dlambrig> Signed-off-by: Joseph Fernandes <josferna> Change-Id: Ic35348303ec21f9bd19f20a48f3141449349668b BUG: 1285688 Reviewed-on: http://review.gluster.org/12762 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Dan Lambright <dlambrig> Tested-by: Dan Lambright <dlambrig>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.7, please open a new bug report. glusterfs-3.7.7 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://www.gluster.org/pipermail/gluster-users/2016-February/025292.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user