andy/glusterfs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

afr: Correction to self-heal-daemon documentation

Browse Source 
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>
This commit is contained in:
Prasanna Kumar Kalever 2015-06-08 12:33:52 +05:30 committed by Kaleb KEITHLEY
parent 78e89fb0a7
commit c42a888fe9
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/developer-guide/afr/self-heal-daemon.md
View File

@ -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>