summaryrefslogtreecommitdiffstats
path: root/xlators/cluster/dht/src/Makefile.am
diff options
context:
space:
mode:
authorShyam <srangana@redhat.com>2014-08-27 15:27:46 -0400
committerVijay Bellur <vbellur@redhat.com>2014-09-02 11:27:23 -0700
commit890ab583a519b3b189a61c5fd563b4326836b988 (patch)
treecbc39727668351cc036af02e2ee393946ad4e59b /xlators/cluster/dht/src/Makefile.am
parent6bf5a2543a9990b718839496ac123ad2141145e7 (diff)
cluster/dht: Treat linkto file rename failure as non-critial error
It is a critical failure iff we fail to rename the cached file if the rename of the linkto failed, it is not a critical failure, and we do not want to lose the created hard link for the new name as that could have been read by other clients. NOTE: If another client is attempting the same oldname -> newname rename, and finds both file names as existing, and are hard links to each other, then FUSE would send in an unlink for oldname. In this time duration if we treat the linkto as a critical error and unlink the newname we created, we would have effectively lost the file to rename operations. Repercussions of treating this as a non-critical error is that we could leave behind a stale linkto file and/or not create the new linkto file, the second case would be rectified by a subsequent lookup, the first case by a rebalance, like for all stale linkto files Change-Id: Ia53ad8b43c3cf8f48ef5b43fd1fec4274e807556 BUG: 1130888 Signed-off-by: Shyam <srangana@redhat.com> Reviewed-on: http://review.gluster.org/8563 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'xlators/cluster/dht/src/Makefile.am')
0 files changed, 0 insertions, 0 deletions