16 files changed, 254 insertions, 27 deletions
diff --git a/doc/admin-guide/en-US/markdown/glossary.md b/doc/admin-guide/en-US/markdown/glossary.md
index 0203319b0..d047622a9 100644
--- a/doc/admin-guide/en-US/markdown/glossary.md
+++ b/doc/admin-guide/en-US/markdown/glossary.md
@@ -169,7 +169,7 @@ Glossary
 **Translator**
 :   Translators (also called xlators) are stackable modules where each
     module has a very specific purpose. Translators are stacked in a
-    hierarchical structure called as graph. A translator recieves data
+    hierarchical structure called as graph. A translator receives data
     from its parent translator, performs necessary operations and then
     passes the data down to its child translator in hierarchy.
 
diff --git a/doc/authentication.txt b/doc/authentication.txt
index 73cb21d73..036a9df99 100644
--- a/doc/authentication.txt
+++ b/doc/authentication.txt
@@ -15,11 +15,11 @@
 ----------------------------------------------------------------------------------------------------
 * options provided in protocol/server:
 	* for username/password based authentication:
-	      option auth.login.<brick>.allow [comma seperated list of usernames using which clients can connect to volume <brick>]
+	      option auth.login.<brick>.allow [comma separated list of usernames using which clients can connect to volume <brick>]
 	      option auth.login.<username>.password <password> #specify password <password> for username <username>
 	* for addr based authentication:
-	      option auth.addr.<brick>.allow [comma seperated list of ip-addresses/unix-paths from which clients are allowed to connect to volume <brick>]
-	      option auth.addr.<brick>.reject [comma seperated list of ip-addresses/unix-paths from which clients are not allowed to connect to volume <brick>]
+	      option auth.addr.<brick>.allow [comma separated list of ip-addresses/unix-paths from which clients are allowed to connect to volume <brick>]
+	      option auth.addr.<brick>.reject [comma separated list of ip-addresses/unix-paths from which clients are not allowed to connect to volume <brick>]
 	* negation operator '!' is used to invert the sense of matching.
 	  Eg., option auth.addr.brick.allow !a.b.c.d #do not allow client from a.b.c.d to connect to volume brick
 	       option auth.addr.brick.reject !w.x.y.z #allow client from w.x.y.z to connect to volume brick
diff --git a/doc/coding-standard.tex b/doc/coding-standard.tex
index 30d412a91..80c11041e 100644
--- a/doc/coding-standard.tex
+++ b/doc/coding-standard.tex
@@ -321,7 +321,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 \texttt{goto} to a single
 point, \texttt{out}.  At that point, the code should detect the error
-that has occured and do appropriate cleanup.
+that has occurred and do appropriate cleanup.
 
 \begin{verbatim}
 int32_t
diff --git a/doc/glusterfs.8 b/doc/glusterfs.8
index 60ad5709b..fc28ef68b 100644
--- a/doc/glusterfs.8
+++ b/doc/glusterfs.8
@@ -122,7 +122,7 @@ Dump fuse traffic to PATH
 Set entry timeout to SECONDS in fuse kernel module (the default is 1).
 .TP
 \fB\-\-gid\-timeout=SECONDS\fR
-Set auxilary group list timeout to SECONDS for fuse translator (the default is 0).
+Set auxiliary group list timeout to SECONDS for fuse translator (the default is 0).
 .TP
 \fB\-\-negative\-timeout=SECONDS\fR
 Set negative timeout to SECONDS in fuse kernel module (the default is 0).
diff --git a/doc/hacker-guide/en-US/markdown/afr.md b/doc/hacker-guide/en-US/markdown/afr.md
index 1be7e39f2..566573a4e 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 178dc142a..368c55534 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
new file mode 100644
index 000000000..73fe775d4
--- /dev/null
+++ b/doc/hacker-guide/en-US/markdown/unittest.md
@@ -0,0 +1,227 @@
+# Unit Tests in GlusterFS
+
+## Overview
+[Art-of-unittesting][definitionofunittest] provides a good definition for unit tests.  A good unit test is:
+
+* Able to be fully automated
+* Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed)
+* Can be run in any order  if part of many other tests
+* Runs in memory (no DB or File access, for example)
+* Consistently returns the same result (You always run the same test, so no random numbers, for example. save those for integration or range tests)
+* Runs fast
+* Tests a single logical concept in the system
+* Readable
+* Maintainable
+* Trustworthy (when you see its result, you don’t need to debug the code just to be sure)
+
+## Cmockery2
+GlusterFS unit test framework is based on [Cmockery2][].  Cmockery provides developers with methods to isolate and test modules written in C language.  It also provides integration with Jenkins by providing JUnit XML compliant unit test results.
+
+Before continuing, you may want to familiarize yourself with Cmockery2 by reading the [usage guide][cmockery2usage].
+
+## Running Unit Tests
+To execute the unit tests, all you need is to type `make check`.  Here is a step-by-step example assuming you just cloned a GlusterFS tree:
+
+```
+$ ./autogen.sh
+$ ./configure --enable-debug
+$ make check
+```
+
+Sample output:
+
+```
+PASS: mem_pool_unittest
+============================================================================
+Testsuite summary for glusterfs 3git
+============================================================================
+# TOTAL: 1
+# PASS:  1
+# SKIP:  0
+# XFAIL: 0
+# FAIL:  0
+# XPASS: 0
+# ERROR: 0
+============================================================================
+```
+
+In this example, `mem_pool_unittest` has multiple tests inside, but `make check` assumes that the program itself is the test, and that is why it only shows one test.  Here is the output when we run `mem_pool_unittest` directly:
+
+```
+$ ./libglusterfs/src/mem_pool_unittest
+[==========] Running 10 test(s).
+[ RUN      ] test_gf_mem_acct_enable_set
+Expected assertion data != ((void *)0) occurred
+[       OK ] test_gf_mem_acct_enable_set
+[ RUN      ] test_gf_mem_set_acct_info_asserts
+Expected assertion xl != ((void *)0) occurred
+Expected assertion size > ((4 + sizeof (size_t) + sizeof (xlator_t *) + 4 + 8) + 8) occurred
+Expected assertion type <= xl->mem_acct.num_types occurred
+[       OK ] test_gf_mem_set_acct_info_asserts
+[ RUN      ] test_gf_mem_set_acct_info_memory
+[       OK ] test_gf_mem_set_acct_info_memory
+[ RUN      ] test_gf_calloc_default_calloc
+[       OK ] test_gf_calloc_default_calloc
+[ RUN      ] test_gf_calloc_mem_acct_enabled
+[       OK ] test_gf_calloc_mem_acct_enabled
+[ RUN      ] test_gf_malloc_default_malloc
+[       OK ] test_gf_malloc_default_malloc
+[ RUN      ] test_gf_malloc_mem_acct_enabled
+[       OK ] test_gf_malloc_mem_acct_enabled
+[ RUN      ] test_gf_realloc_default_realloc
+[       OK ] test_gf_realloc_default_realloc
+[ RUN      ] test_gf_realloc_mem_acct_enabled
+[       OK ] test_gf_realloc_mem_acct_enabled
+[ RUN      ] test_gf_realloc_ptr
+Expected assertion ((void *)0) != ptr occurred
+[       OK ] test_gf_realloc_ptr
+[==========] 10 test(s) run.
+[  PASSED  ] 10 test(s).
+[  FAILED  ] 0 test(s).
+[  REPORT  ] Created libglusterfs_mem_pool_xunit.xml report
+```
+
+
+## Writing Unit Tests
+
+### Enhancing your C functions
+
+#### Programming by Contract
+Add the following to your C file:
+
+```c
+#include <cmockery/pbc.h>
+```
+
+```c
+/*
+ * Programming by Contract is a programming methodology
+ * which binds the caller and the function called to a
+ * contract. The contract is represented using Hoare Triple:
+ *      {P} C {Q}
+ * where {P} is the precondition before executing command C,
+ * and {Q} is the postcondition.
+ *
+ * See also:
+ * http://en.wikipedia.org/wiki/Design_by_contract
+ * http://en.wikipedia.org/wiki/Hoare_logic
+ * http://dlang.org/dbc.html
+ */
+ #ifndef CMOCKERY_PBC_H_
+#define CMOCKERY_PBC_H_
+
+#if defined(UNIT_TESTING) || defined (DEBUG)
+
+#include <assert.h>
+
+/*
+ * Checks caller responsibility against contract
+ */
+#define REQUIRE(cond) assert(cond)
+
+/*
+ * Checks function reponsability against contract.
+ */
+#define ENSURE(cond) assert(cond)
+
+/*
+ * While REQUIRE and ENSURE apply to functions, INVARIANT
+ * applies to classes/structs.  It ensures that intances
+ * 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);
+
+#else
+#define REQUIRE(cond) do { } while (0);
+#define ENSURE(cond) do { } while (0);
+#define INVARIANT(invariant_fnc) do{ } while (0);
+
+#endif /* defined(UNIT_TESTING) || defined (DEBUG) */
+#endif /* CMOCKERY_PBC_H_ */
+```
+
+##### Example
+This is an _extremely_ simple example:
+
+```c
+int divide (int n, int d)
+{
+    int ans;
+
+    REQUIRE(d != 0);
+
+    ans = n / d;
+
+    // As code is added to this function throughout its lifetime,
+    // ENSURE will assert that data will be returned
+    // according to the contract.  Again this is an
+    // extremely simple example. :-D
+    ENSURE( ans == (n / d) );
+
+    return ans;
+}
+
+```
+
+##### Important Note
+`REQUIRE`, `ENSURE`, and `INVARIANT` are only available when `DEBUG` or `UNIT_TESTING` are set in the CFLAGS.  You must pass `--enable-debug` to `./configure` to enable PBC on your non-unittest builds.
+
+#### Overriding functions
+Cmockery2 provides its own memory allocation functions which check for buffer overrun and memory leaks.  The following header file must be included **last** to be able to override any of the memory allocation functions:
+
+```c
+#include <cmockery/cmockery_override.h>
+```
+
+This file will only take effect with the `UNIT_TESTING` CFLAG is set.
+
+### Creating a unit test
+Once you identify the C file you would like to test, first create a `unittest` directory under the directory where the C file is located.  This will isolate the unittests to a different directory.
+
+Next, you need to edit the `Makefile.am` file in the directory where your C file is located.  Initialize the
+`Makefile.am` if it does not already have the following sections:
+
+```
+#### UNIT TESTS #####
+CLEANFILES += *.gcda *.gcno *_xunit.xml
+noinst_PROGRAMS =
+TESTS =
+```
+
+Now you can add the following for each of the unit tests that you would like to build:
+
+```
+### UNIT TEST xxx_unittest ###
+xxx_unittest_CPPFLAGS = $(UNITTEST_CPPFLAGS) $(xxx_CPPFLAGS)
+xxx_unittest_SOURCES = xxx.c \
+                       unittest/xxx_unittest.c
+xxx_unittest_CFLAGS = $(UNITTEST_CFLAGS)
+xxx_unittest_LDADD = $(UNITTEST_LDADD)
+xxx_unittest_LDFLAGS = $(UNITTEST_LDFLAGS)
+noinst_PROGRAMS += xxx_unittest
+TESTS += xxx_unittest
+```
+
+Where `xxx` is the name of your C file. For example, look at `libglusterfs/src/Makefile.am`.
+
+Copy the simple unit test from `cmockery2/src/example/run_tests.c` to `unittest/xxx_unittest.c`.  If you would like to see an example of a unit test, please refer to `libglusterfs/src/unittest/mem_pool_unittest.c`.
+
+#### Mocking
+You may see that the linker will complain about missing functions needed by the C file you would like to test.  Identify the required functions, then place their stubs in a file called `unittest/xxx_mock.c`, then include this file in `Makefile.am` in `xxx_unittest_SOURCES`.  This will allow you to you Cmockery2's mocking functions.
+
+#### Running the unit test
+You can type `make` in the directory where the C file is located.  Once you built it and there are no errors, you can execute the test either by directly executing the program (in our example above it is called `xxx_unittest` ), or by running `make check`.
+
+#### Debugging
+Sometimes you may need to debug your unit test.  To do that, you will have to point `gdb` to the actual binary which is located in the `.libs` subdirectory.  For example, you can do the following from the root of the source tree to debug `mem_pool_unittest`:
+
+```
+$ export LD_LIBRARY_PATH=cmockery2/.libs
+$ gdb ./libglusterfs/src/.libs/mem_pool_unittest
+```
+
+
+[Cmockery2]: https://github.com/lpabon/cmockery2
+[definitionofunittest]: http://artofunittesting.com/definition-of-a-unit-test/
+[cmockery2usage]: https://github.com/lpabon/cmockery2/blob/master/doc/usage.md
diff --git a/doc/hacker-guide/en-US/markdown/write-behind.md b/doc/hacker-guide/en-US/markdown/write-behind.md
index e20682249..0d78964fa 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
 ------------
diff --git a/doc/legacy/errno.list.linux.txt b/doc/legacy/errno.list.linux.txt
index cc868644b..3f3b18c46 100644
--- a/doc/legacy/errno.list.linux.txt
+++ b/doc/legacy/errno.list.linux.txt
@@ -1273,7 +1273,7 @@ APR_DECLARE(char *) apr_strerror(apr_status_t statcode, char *buf,
 #define APR_STATUS_IS_EHOSTUNREACH(s)    ((s) == APR_EHOSTUNREACH)
 /** network is unreachable */
 #define APR_STATUS_IS_ENETUNREACH(s)     ((s) == APR_ENETUNREACH)
-/** inappropiate file type or format */
+/** inappropriate file type or format */
 #define APR_STATUS_IS_EFTYPE(s)          ((s) == APR_EFTYPE)
 /** broken pipe */
 #define APR_STATUS_IS_EPIPE(s)           ((s) == APR_EPIPE)
diff --git a/doc/legacy/errno.list.macosx.txt b/doc/legacy/errno.list.macosx.txt
index 4954e03d8..2dff28cd3 100644
--- a/doc/legacy/errno.list.macosx.txt
+++ b/doc/legacy/errno.list.macosx.txt
@@ -1212,7 +1212,7 @@ APR_DECLARE(char *) apr_strerror(apr_status_t statcode, char *buf,
 #define APR_STATUS_IS_EHOSTUNREACH(s)    ((s) == APR_EHOSTUNREACH)
 /** network is unreachable */
 #define APR_STATUS_IS_ENETUNREACH(s)     ((s) == APR_ENETUNREACH)
-/** inappropiate file type or format */
+/** inappropriate file type or format */
 #define APR_STATUS_IS_EFTYPE(s)          ((s) == APR_EFTYPE)
 /** broken pipe */
 #define APR_STATUS_IS_EPIPE(s)           ((s) == APR_EPIPE)
diff --git a/doc/legacy/hacker-guide/call-stub.txt b/doc/legacy/hacker-guide/call-stub.txt
index 021037a35..cab8e4d55 100644
--- a/doc/legacy/hacker-guide/call-stub.txt
+++ b/doc/legacy/hacker-guide/call-stub.txt
@@ -1,6 +1,6 @@
 creating a call stub and pausing a call
 ---------------------------------------
-libglusterfs provides seperate API to pause each of the fop. parameters to each API is
+libglusterfs provides separate API to pause each of the fop. parameters to each API is
 @frame - call frame which has to be used to resume the call at call_resume().
 @fn    - procedure to call during call_resume().
        NOTE: @fn should exactly take the same type and number of parameters that
diff --git a/doc/legacy/hacker-guide/replicate.txt b/doc/legacy/hacker-guide/replicate.txt
index 133c72afa..ad5b352a8 100644
--- a/doc/legacy/hacker-guide/replicate.txt
+++ b/doc/legacy/hacker-guide/replicate.txt
@@ -148,7 +148,7 @@ Each of the four major groups has its own algorithm:
          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
diff --git a/doc/legacy/replicate.lyx b/doc/legacy/replicate.lyx
index 58ba6b2e0..e3d081191 100644
--- a/doc/legacy/replicate.lyx
+++ b/doc/legacy/replicate.lyx
@@ -293,7 +293,7 @@ Locking and Change Log
 To ensure consistency across subvolumes, replicate holds a lock whenever a modificatio
 n is being made to a file or directory.
  By default, replicate considers the first subvolume as the sole lock server.
- However, the number of lock servers can be increased upto the total number
+ However, the number of lock servers can be increased up to the total number
  of subvolumes.
 \end_layout
 
diff --git a/doc/legacy/solaris-related-xattrs.txt b/doc/legacy/solaris-related-xattrs.txt
index 3a4643948..fa41e2900 100644
--- a/doc/legacy/solaris-related-xattrs.txt
+++ b/doc/legacy/solaris-related-xattrs.txt
@@ -9,7 +9,7 @@ the leveraging of existing file system interface functionality to
 support the construction, deletion and manipulation of attributes.
 
 But as we have tested through this functionality provided by Solaris
-we have come accross two major issues as written below.
+we have come across two major issues as written below.
 
 1. Symlink XATTR_NOFOLLOW not present for creating extended attributes
    directly on the symlinks like other platforms Linux,MAC-OSX,BSD etc.
diff --git a/doc/legacy/user-guide.info b/doc/legacy/user-guide.info
index 2bbadb351..eae0ef10b 100644
--- a/doc/legacy/user-guide.info
+++ b/doc/legacy/user-guide.info
@@ -234,7 +234,7 @@ recommended that all users use the patched FUSE.
      GlusterFS has been increased to 1MB, permitting large reads and
      writes to be sent in bigger chunks.
 
-   * The kernel's read-ahead boundry has been extended upto 1MB.
+   * The kernel's read-ahead boundary has been extended up to 1MB.
 
    * Block size returned in the `stat()'/`fstat()' calls tuned to 1MB,
      to make cp and similar commands perform I/O using that block size.
@@ -527,7 +527,7 @@ module loaded. You can ensure this by running:
      [root@server]# modprobe fuse
 
    Before we can run the GlusterFS client or server programs, we need
-to write two files called _volume specifications_ (equivalently refered
+to write two files called _volume specifications_ (equivalently referred
 to as _volfiles_).  The volfile describes the _translator tree_ on a
 node. The next chapter will explain the concepts of `translator' and
 `volume specification' in detail. For now, just assume that the volfile
@@ -1161,7 +1161,7 @@ alu.order' configuration directive.
    Each sub-scheduler needs to know two things: when to kick in (the
 entry-threshold), and how long to stay in control (the exit-threshold).
 For example: when unifying three disks of 100GB, keeping an exact
-balance of disk-usage is not necesary. Instead, there could be a 1GB
+balance of disk-usage is not necessary. Instead, there could be a 1GB
 margin, which can be used to nicely balance other factors, such as
 read-usage. The disk-usage scheduler can be told to kick in only when a
 certain threshold of discrepancy is passed, such as 1GB. When it
@@ -1557,7 +1557,7 @@ can be pipelined.  This mode of write-behind operation is best used on
 the client side, to enable decreased write latency for the application.
 
    The write-behind translator can also aggregate write requests. If the
-`aggregate-size' option is specified, then successive writes upto that
+`aggregate-size' option is specified, then successive writes up to that
 size are accumulated and written in a single operation. This mode of
 operation is best used on the server side, as this will decrease the
 disk's head movement when multiple files are being written to in
@@ -1611,7 +1611,7 @@ useful in a web hosting environment, where most clients will simply
 read some files and only a few will write to them).
 
    The IO cache translator reads data from its child in `page-size'
-chunks.  It caches data upto `cache-size' bytes. The cache is
+chunks.  It caches data up to `cache-size' bytes. The cache is
 maintained as a prioritized least-recently-used (LRU) list, with
 priorities determined by user-specified patterns to match filenames.
 
diff --git a/doc/legacy/user-guide.texi b/doc/legacy/user-guide.texi
index 8e429853f..31ff9cf30 100644
--- a/doc/legacy/user-guide.texi
+++ b/doc/legacy/user-guide.texi
@@ -260,7 +260,7 @@ The specific changes made to @acronym{FUSE} are:
 @itemize
 @item The communication channel size between @acronym{FUSE} kernel module and GlusterFS has been increased to 1MB, permitting large reads and writes to be sent in bigger chunks.
 
-@item The kernel's read-ahead boundry has been extended upto 1MB.
+@item The kernel's read-ahead boundary has been extended up to 1MB.
 
 @item Block size returned in the @command{stat()}/@command{fstat()} calls tuned to 1MB, to make cp and similar commands perform I/O using that block size.
 
@@ -554,7 +554,7 @@ can ensure this by running:
 @end example
 
 Before we can run the GlusterFS client or server programs, we need to write
-two files called @emph{volume specifications} (equivalently refered to as @emph{volfiles}).
+two files called @emph{volume specifications} (equivalently referred to as @emph{volfiles}).
 The volfile describes the @emph{translator tree} on a node. The next chapter will
 explain the concepts of `translator' and `volume specification' in detail. For now,
 just assume that the volfile is like an NFS @command{/etc/export} file.
@@ -1198,7 +1198,7 @@ and in which order to evaluate them. This is done through the
 Each sub-scheduler needs to know two things: when to kick in (the
 entry-threshold), and how long to stay in control (the
 exit-threshold). For example: when unifying three disks of 100GB,
-keeping an exact balance of disk-usage is not necesary. Instead, there
+keeping an exact balance of disk-usage is not necessary. Instead, there
 could be a 1GB margin, which can be used to nicely balance other
 factors, such as read-usage. The disk-usage scheduler can be told to
 kick in only when a certain threshold of discrepancy is passed, such
@@ -1597,7 +1597,7 @@ This mode of write-behind operation is best used on the client side, to
 enable decreased write latency for the application.
 
 The write-behind translator can also aggregate write requests. If the
-@command{aggregate-size} option is specified, then successive writes upto that
+@command{aggregate-size} option is specified, then successive writes up to that
 size are accumulated and written in a single operation. This mode of operation
 is best used on the server side, as this will decrease the disk's head movement
 when multiple files are being written to in parallel.
@@ -1655,7 +1655,7 @@ useful in a web hosting environment, where most clients will simply
 read some files and only a few will write to them).
 
 The IO cache translator reads data from its child in @command{page-size} chunks.
-It caches data upto @command{cache-size} bytes. The cache is maintained as
+It caches data up to @command{cache-size} bytes. The cache is maintained as
 a prioritized least-recently-used (@acronym{LRU}) list, with priorities determined
 by user-specified patterns to match filenames.