summaryrefslogtreecommitdiffstats
path: root/doc/hacker-guide
diff options
context:
space:
mode:
authorAkshataDM <oxta28@gmail.com>2014-03-15 23:33:38 +0530
committerAnand Avati <avati@redhat.com>2014-03-16 11:57:21 -0700
commit9565ac3328dc91bd721a65b6d4e7957929e9ed59 (patch)
tree41295e4564d44e2d5f5e34914b786b1568860207 /doc/hacker-guide
parent79d2a9e5b83b4d773e5b821c5c55f24718745cb7 (diff)
Made spelling changes to 19 files
Change-Id: If91cf44578fe0b5176ea01ae5c5962e31606f640 BUG: 1075417 Signed-off-by: AkshataDM <oxta28@gmail.com> Reviewed-on: http://review.gluster.org/7280 Reviewed-by: Varun Shastry <vshastry@redhat.com> Reviewed-by: Anand Avati <avati@redhat.com> Tested-by: Anand Avati <avati@redhat.com>
Diffstat (limited to 'doc/hacker-guide')
-rw-r--r--doc/hacker-guide/en-US/markdown/afr.md2
-rw-r--r--doc/hacker-guide/en-US/markdown/coding-standard.md2
-rw-r--r--doc/hacker-guide/en-US/markdown/unittest.md4
-rw-r--r--doc/hacker-guide/en-US/markdown/write-behind.md6
4 files changed, 7 insertions, 7 deletions
diff --git a/doc/hacker-guide/en-US/markdown/afr.md b/doc/hacker-guide/en-US/markdown/afr.md
index 1be7e39f25f..566573a4e26 100644
--- a/doc/hacker-guide/en-US/markdown/afr.md
+++ b/doc/hacker-guide/en-US/markdown/afr.md
@@ -143,7 +143,7 @@ Self heal
* consider the entry with the highest `AFR_METADATA_PENDING` number as
definitive and replicate its attributes on children.
* If entry is a directory:
- * Consider the entry with the higest `AFR_ENTRY_PENDING` number as
+ * Consider the entry with the highest `AFR_ENTRY_PENDING` number as
definitive and replicate its contents on all children.
* If any two entries have non-matching types (i.e., one is file and
other is directory):
diff --git a/doc/hacker-guide/en-US/markdown/coding-standard.md b/doc/hacker-guide/en-US/markdown/coding-standard.md
index 178dc142ae3..368c5553464 100644
--- a/doc/hacker-guide/en-US/markdown/coding-standard.md
+++ b/doc/hacker-guide/en-US/markdown/coding-standard.md
@@ -341,7 +341,7 @@ This is the recommended template for any fop. In the beginning come
the initializations. After that, the `success' control flow should be
linear. Any error conditions should cause a `goto` to a single
point, `out`. At that point, the code should detect the error
-that has occured and do appropriate cleanup.
+that has occurred and do appropriate cleanup.
```
int32_t
diff --git a/doc/hacker-guide/en-US/markdown/unittest.md b/doc/hacker-guide/en-US/markdown/unittest.md
index 65e8b85d55c..73fe775d450 100644
--- a/doc/hacker-guide/en-US/markdown/unittest.md
+++ b/doc/hacker-guide/en-US/markdown/unittest.md
@@ -115,7 +115,7 @@ Add the following to your C file:
#include <assert.h>
/*
- * Checks caller responsability against contract
+ * Checks caller responsibility against contract
*/
#define REQUIRE(cond) assert(cond)
@@ -127,7 +127,7 @@ Add the following to your C file:
/*
* While REQUIRE and ENSURE apply to functions, INVARIANT
* applies to classes/structs. It ensures that intances
- * of the class/struct are consistant. In other words,
+ * of the class/struct are consistent. In other words,
* that the instance has not been corrupted.
*/
#define INVARIANT(invariant_fnc) do{ (invariant_fnc) } while (0);
diff --git a/doc/hacker-guide/en-US/markdown/write-behind.md b/doc/hacker-guide/en-US/markdown/write-behind.md
index e20682249e8..0d78964fa20 100644
--- a/doc/hacker-guide/en-US/markdown/write-behind.md
+++ b/doc/hacker-guide/en-US/markdown/write-behind.md
@@ -12,7 +12,7 @@ On a regular translator tree without write-behind, control flow is like this:
1. application makes a `write()` system call.
2. VFS ==> FUSE ==> `/dev/fuse`.
3. fuse-bridge initiates a glusterfs `writev()` call.
-4. `writev()` is `STACK_WIND()`ed upto client-protocol or storage translator.
+4. `writev()` is `STACK_WIND()`ed up to client-protocol or storage translator.
5. client-protocol, on receiving reply from server, starts `STACK_UNWIND()` towards the fuse-bridge.
On a translator tree with write-behind, control flow is like this:
@@ -20,7 +20,7 @@ On a translator tree with write-behind, control flow is like this:
1. application makes a `write()` system call.
2. VFS ==> FUSE ==> `/dev/fuse`.
3. fuse-bridge initiates a glusterfs `writev()` call.
-4. `writev()` is `STACK_WIND()`ed upto write-behind translator.
+4. `writev()` is `STACK_WIND()`ed up to write-behind translator.
5. write-behind adds the write buffer to its internal queue and does a `STACK_UNWIND()` towards the fuse-bridge.
write call is completed in application's percepective. after
@@ -46,7 +46,7 @@ writev() calls from fuse-bridge. Blocking is only from application's
perspective. Write-behind does `STACK_WIND()` to child translator
straight-away, but hold behind the `STACK_UNWIND()` towards fuse-bridge.
`STACK_UNWIND()` is done only once write-behind gets enough replies to
-accomodate for currently blocked request.
+accommodate for currently blocked request.
Flush behind
------------