REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#1) for review on master by Joseph Fernandes
REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#2) for review on master by Joseph Fernandes
REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#3) for review on master by Joseph Fernandes
REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#4) for review on master by Joseph Fernandes
REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#5) for review on master by Joseph Fernandes
REVIEW: http://review.gluster.org/12711 (tier/ctr: Correcting rename logic) posted (#6) for review on master by Joseph Fernandes
COMMIT: http://review.gluster.org/12711 committed in master by Dan Lambright (dlambrig) ------ commit 9b151f4ddc2636607b15424c94a09f619f2e5cb8 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 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>
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.8.0, please open a new bug report. glusterfs-3.8.0 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] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user