cleanup: typos in doc

doc/kernel/persistent-data.txt

@@ -13,7 +13,7 @@ different targets were rolling their own data structures, for example:
 Maintaining these data structures takes a lot of work, so if possible
 we'd like to reduce the number.
 
-The persistent-data library is an attempt to provide a re-usable
+The persistent-data library is an attempt to provide a reusable
 framework for people who want to store metadata in device-mapper
 targets.  It's currently used by the thin-provisioning target and an
 upcoming hierarchical storage target.

doc/kernel/zoned.txt

@@ -41,7 +41,7 @@ metadata.
 The zones of the device are separated into 2 types:
 
 1) Metadata zones: these are conventional zones used to store metadata.
-Metadata zones are not reported as useable capacity to the user.
+Metadata zones are not reported as usable capacity to the user.
 
 2) Data zones: all remaining zones, the vast majority of which will be
 sequential zones used exclusively to store user data. The conventional

doc/lvm_fault_handling.txt

@@ -86,7 +86,7 @@ are as follows:
   the policies outlined in the LVM configuration file - usually,
   /etc/lvm/lvm.conf.  Once this operation is complete, the logical volumes
   will be consistent.  However, the volume group will still be inconsistent -
-  due to the refernced-but-missing device/PV - and operations will still be
+  due to the referenced-but-missing device/PV - and operations will still be
   restricted to the aforementioned actions until either the device is
   restored or 'vgreduce --removemissing' is run.
 

doc/lvmetad_design.txt

@@ -108,7 +108,7 @@ really an orphan and enable its usage for creating or extending VGs. In
 practice, the decision might be governed by a timeout or assumed immediately --
 the former case is a little safer, the latter is probably more transparent. I
 am not very keen on using timeouts and we can probably assume that the admin
-won't blindly try to re-use devices in a way that would trip up LVM in this
+won't blindly try to reuse devices in a way that would trip up LVM in this
 respect. I would be in favour of just assuming that metadata-less VGs with no
 known referencing VGs are orphans -- after all, this is the same approach as we
 use today. The metadata balancing support may stress this a bit more than the
@@ -153,7 +153,7 @@ Protocol & co.
 
 I expect a simple text-based protocol executed on top of an Unix Domain Socket
 to be the communication interface for lvmetad. Ideally, the requests and
-replies will be well-formed "config file" style strings, so we can re-use
+replies will be well-formed "config file" style strings, so we can reuse
 existing parsing infrastructure.
 
 Since we already have two daemons, I would probably look into factoring some

doc/refactoring.txt

@@ -56,7 +56,7 @@ Device mapper
 -------------
 
 As well as the low level dm-ioctl driving code we need to have all our dm 'best
-practise' stuff in here.  For instance this is the code that decides to use the
+practice' stuff in here.  For instance this is the code that decides to use the
 mirror target to move some data around; that knows to suspend a thin volume
 before taking a snapshot of it.  This module is going to have a lot more code
 in it than the current libdevmapper.
@@ -150,7 +150,7 @@ interface to get round.
 'lib' is where the bulk of our code currently is.  Dependency-wise the code is
 a bit like a ball of string.  So splitting it up is going to take time.  We can
 probably pull code pretty quickly into the 'metadata model' dir.  But factoring
-out the dm best practises stuff is going to require splitting at least
+out the dm best practices stuff is going to require splitting at least
 files, and probably functions.  Certainly not something that can be done in one
 go.  System should just be a question of cherry picking functions.
 

doc/release-notes/template.mdwn

@@ -25,7 +25,7 @@ TODO: It would be nice if we could use a real session output, so we could test t
 Changes in command line
 -----------------------
 
-Describe important changes in command line tools, especially any chnages of behavior, which user must be aware of:
+Describe important changes in command line tools, especially any changes of behavior, which user must be aware of:
 
 * New options
 * Removed options

doc/testing.txt

@@ -29,7 +29,7 @@ LVM2 that is running the LV's on my development box.
    variable LVM_SYSTEM_DIR to point to your config directory
    (/etc/lvm_loops in my case).
 
-5) It's a good idea to do a vgscan to initialise the filters:
+5) It's a good idea to do a vgscan to initialize the filters:
 
    export LVM_SYSTEM_DIR=/etc/lvm_loops
    ./lvm vgscan