afr: Correction to self-heal-daemon documentation

The reference in the documentation is outdated and need path modification

Change-Id: Ia3712b5064b35b85f83d3b920ecba35dd867f6d3
BUG: 1229127
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-on: http://review.gluster.org/11117
Reviewed-by: Ravishankar N <ravishankar@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>

1 files changed, 9 insertions, 10 deletions

diff --git a/doc/developer-guide/afr/self-heal-daemon.md b/doc/developer-guide/afr/self-heal-daemon.md
index 1fd8f08062a..d5e081f5f49 100644
--- a/doc/developer-guide/afr/self-heal-daemon.md
+++ b/doc/developer-guide/afr/self-heal-daemon.md
@@ -8,12 +8,12 @@ This document only describes how the shd works for replicate (AFR) volumes.
 
 The shd is launched by glusterd when the volume starts (only if the volume includes a replicate configuration). The graph
 of the shd process in every node contains the following: The io-stats which is the top most xlator, its children being the
-replicate xlators (subvolumes) of *only* the bricks present in that particular node node, and finally *all* the client xlators that are the children of the replicate xlators.
+replicate xlators (subvolumes) of *only* the bricks present in that particular node, and finally *all* the client xlators that are the children of the replicate xlators.
 
 The shd does two types of self-heal crawls: Index heal and Full heal. For both these types of crawls, the basic idea is the same:  
 For each file encountered while crawling, perform metadata, data and entry heals under appropriate locks.  
 * An overview of how each of these heals is performed is detailed in the 'Self-healing' section of *doc/features/afr-v1.md*
-* The different file locks which the shd takes for each of these heals is detailed in *doc/code/xlators/cluster/afr/afr-locks-evolution.md*
+* The different file locks which the shd takes for each of these heals is detailed in *doc/developer-guide/afr/afr-locks-evolution.md*
 
 Metadata heal refers to healing extended attributes, mode and permissions of a file or directory.
 Data heal refers to healing the file contents.
@@ -30,9 +30,9 @@ Only one heal can be in progress at one time, irrespective of reason why it was
 Only one heal can be queued while the first one is running. If an Index heal is queued, it can be overridden by queuing a Full heal and not vice-versa.  Also, before processing
 each entry in index heal, a check is made if a full heal is queued. If it is, then the index heal is aborted so that the full heal can proceed. 
 
-In index heal, each shd reads the entries present inside .glusterfs/indices/xattrop folder and triggers heal on each entry with appropriate locks.
-The .glusterfs/indices/xattrop directory contains a base entry of the name "xattrop-<virtual-gfid-string>". All other entries are hardlinks to the base entry. The
-*names* of the hardlinks are the gfid strings of the files that may need heal. 
+In index heal, each shd reads the entries present inside .glusterfs/indices/xattrop/ folder and triggers heal on each entry with appropriate locks.
+The .glusterfs/indices/xattrop/ directory contains a base entry of the name "xattrop-<virtual-gfid-string>". All other entries are hardlinks to the base entry. The
+*names* of the hardlinks are the gfid strings of the files that may need heal.
 
 When a client (mount) performs an operation on the file, the index xlator present in each brick process adds the hardlinks in the pre-op phase of the FOP's transaction
 and removes it in post-op phase if the operation is successful. Thus if an entry is present inside the .glusterfs/indices/xattrop directory when there is no I/O 
@@ -41,7 +41,7 @@ happening on the file, it means the file needs healing (or atleast an examinatio
 ####Index heal steps:
 <pre><code>
 In shd process of *each node* {
-        opendir +readdir (.glusterfs/indices/xattrop)
+        opendir +readdir (.glusterfs/indices/xattrop/)
         for each entry inside it {
                 self_heal_entry() //Explained below.
         }
@@ -54,15 +54,15 @@ self_heal_entry() {
                 take appropriate locks
                 determine source and sinks from AFR changelog xattrs	
                 perform whatever heal is needed (any of metadata, data and entry heal in that order)
-                clear changelog xattrs and hardlink inside .glusterfs/indices/xattrop
+                clear changelog xattrs and hardlink inside .glusterfs/indices/xattrop/
         }
 }
 </code></pre>
 
 Note:
-* If the gfid hardlink is present in the .glusterfs/indices/xattrop of both replica bricks, then each shd will try to heal the file but only one of them will be able to proceed due to the self-heal domain lock.
+* If the gfid hardlink is present in the .glusterfs/indices/xattrop/ of both replica bricks, then each shd will try to heal the file but only one of them will be able to proceed due to the self-heal domain lock.
 
-* While processing entries inside .glusterfs/indices/xattrop, if shd encounters an entry whose parent is yet to be healed, it will skip it and it will be picked up in the next crawl.
+* While processing entries inside .glusterfs/indices/xattrop/, if shd encounters an entry whose parent is yet to be healed, it will skip it and it will be picked up in the next crawl.
 
 * If a file is in data/ metadata split-brain, it will not be healed.
 
@@ -85,7 +85,6 @@ In shd process of *highest UUID node per replica* {
                         /* Recurse*/
                         again opendir+readdir (directory) followed by self_heal_entry() of each entry.
                 }
-                
         }
 }
 </code></pre>