cluster/afr: Handle transient parent-entry xactions in lookup

This patch addresses the case when the lookup on an entry is performed
while it is being renamed. The lookup can possibly return 2 different
gfids when lookup on one subvol reached before rename and on other
after rename. In such cases the conflicting entry self-heal is
triggered to resolve the issue, but if there are lot entry transactions
going on the parent directory of the entry then the non-blocking
locks could fail resulting in EIO. To avoid this, lookup queries
locks xlator if there are any parent-entrylk on entry's basename.
If afr finds that there are such locks and gfids are differing then
it chooses the file with latest ctime as the iatt of the entry.
This solution is not foolproof, but it decreases the probability of
hitting the EIO. The correct solution is to take blocking locks on
the parent-entry to find out the correct source. Taking blocking
locks in lookup is not good. One stale entry lock can hang the whole
filesystem. So we chose to go with this for now.

Change-Id: Ibebb6c3074f56f80a96893b6bf5b77941e30d400
BUG: 765551
Signed-off-by: Pranith Kumar K <pranithk@gluster.com>
Reviewed-on: http://review.gluster.com/3179
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>

0 files changed, 0 insertions, 0 deletions