doc: fix typos in documentation

Typos found with codespell.

9 files changed, 18 insertions, 18 deletions

diff --git a/doc/kernel/cache-policies.txt b/doc/kernel/cache-policies.txt
index d3ca8af21..1436dbc6e 100644
--- a/doc/kernel/cache-policies.txt
+++ b/doc/kernel/cache-policies.txt
@@ -67,7 +67,7 @@ the entries (each hotspot block covers a larger area than a single
 cache block).
 
 All this means smq uses ~25bytes per cache block.  Still a lot of
-memory, but a substantial improvement nontheless.
+memory, but a substantial improvement nonetheless.
 
 Level balancing:
 mq placed entries in different levels of the multiqueue structures
diff --git a/doc/kernel/crypt.txt b/doc/kernel/crypt.txt
index 3b3e1de21..df18572f9 100644
--- a/doc/kernel/crypt.txt
+++ b/doc/kernel/crypt.txt
@@ -35,7 +35,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
         capi:authenc(hmac(sha256),xts(aes))-random
         capi:rfc7539(chacha20,poly1305)-random
 
-    The /proc/crypto contains a list of curently loaded crypto modes.
+    The /proc/crypto contains a list of currently loaded crypto modes.
 
 <key>
     Key used for encryption. It is encoded either as a hexadecimal number
@@ -81,7 +81,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
 
 <#opt_params>
     Number of optional parameters. If there are no optional parameters,
-    the optional paramaters section can be skipped or #opt_params can be zero.
+    the optional parameters section can be skipped or #opt_params can be zero.
     Otherwise #opt_params is the number of following arguments.
 
     Example of optional parameters section:
diff --git a/doc/kernel/integrity.txt b/doc/kernel/integrity.txt
index 03a3b956a..0822de802 100644
--- a/doc/kernel/integrity.txt
+++ b/doc/kernel/integrity.txt
@@ -120,7 +120,7 @@ journal_crypt:algorithm(:key)	(the key is optional)
 	"salsa20", "ctr(aes)" or "ecb(arc4)").
 
 	The journal contains history of last writes to the block device,
-	an attacker reading the journal could see the last sector nubmers
+	an attacker reading the journal could see the last sector numbers
 	that were written. From the sector numbers, the attacker can infer
 	the size of files that were written. To protect against this
 	situation, you can encrypt the journal.
diff --git a/doc/kernel/verity.txt b/doc/kernel/verity.txt
index 89fd8f9a2..9822f1d61 100644
--- a/doc/kernel/verity.txt
+++ b/doc/kernel/verity.txt
@@ -65,7 +65,7 @@ Construction Parameters
 
 <#opt_params>
     Number of optional parameters. If there are no optional parameters,
-    the optional paramaters section can be skipped or #opt_params can be zero.
+    the optional parameters section can be skipped or #opt_params can be zero.
     Otherwise #opt_params is the number of following arguments.
 
     Example of optional parameters section:
diff --git a/doc/lvm2-raid.txt b/doc/lvm2-raid.txt
index a6f091543..a3226f230 100644
--- a/doc/lvm2-raid.txt
+++ b/doc/lvm2-raid.txt
@@ -37,7 +37,7 @@ segment type.  The available RAID types are:
 	"raid6_nr" - RAID6 Rotating parity N with data restart
 	"raid6_nc" - RAID6 Rotating parity N with data continuation
 The exception to 'no shorthand options' will be where the RAID implementations
-can displace traditional tagets.  This is the case with 'mirror' and 'raid1'.
+can displace traditional targets.  This is the case with 'mirror' and 'raid1'.
 In this case, "mirror_segtype_default" - found under the "global" section in
 lvm.conf - can be set to "mirror" or "raid1".  The segment type inferred when
 the '-m' option is used will be taken from this setting.  The default segment
@@ -104,7 +104,7 @@ and 4 devices for RAID 6/10.
 
 lvconvert should work exactly as it does now when dealing with mirrors -
 even if(when) we switch to MD RAID1.  Of course, there are no plans to
-allow the presense of the metadata area to be configurable (e.g. --corelog).
+allow the presence of the metadata area to be configurable (e.g. --corelog).
 It will be simple enough to detect if the LV being up/down-converted is
 new or old-style mirroring.
 
@@ -120,7 +120,7 @@ RAID4 to RAID5 or RAID5 to RAID6.
 Line 02/03/04:
 These are familiar options - all of which would now be available as options
 for change.  (However, it'd be nice if we didn't have regionsize in there.
-It's simple on the kernel side, but is just an extra - often unecessary -
+It's simple on the kernel side, but is just an extra - often unnecessary -
 parameter to many functions in the LVM codebase.)
 
 Line 05:
@@ -375,8 +375,8 @@ the slot.  Even the names of the images will be renamed to properly reflect
 their index in the array.  Unlike the "mirror" segment type, you will never have
 an image named "*_rimage_1" occupying the index position 0.
 
-As with adding images, removing images holds off on commiting LVM metadata
-until all possible changes have been made.  This reduces the likelyhood of bad
+As with adding images, removing images holds off on committing LVM metadata
+until all possible changes have been made.  This reduces the likelihood of bad
 intermediate stages being left due to a failure of operation or machine crash.
 
 RAID1 '--splitmirrors', '--trackchanges', and '--merge' operations
diff --git a/doc/lvm_fault_handling.txt b/doc/lvm_fault_handling.txt
index 53b447eac..196b782db 100644
--- a/doc/lvm_fault_handling.txt
+++ b/doc/lvm_fault_handling.txt
@@ -87,7 +87,7 @@ are as follows:
   /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
-  restricted to the aformentioned actions until either the device is
+  restricted to the aforementioned actions until either the device is
   restored or 'vgreduce --removemissing' is run.
 
 Device Revival (transient failures):
@@ -135,9 +135,9 @@ If a mirror is not 'in-sync', a read failure will produce an I/O error.
 This error will propagate all the way up to the applications above the
 logical volume (e.g. the file system).  No automatic intervention will
 take place in this case either.  It is up to the user to decide what
-can be done/salvaged in this senario.  If the user is confident that the
+can be done/salvaged in this scenario.  If the user is confident that the
 images of the mirror are the same (or they are willing to simply attempt
-to retreive whatever data they can), 'lvconvert' can be used to eliminate
+to retrieve whatever data they can), 'lvconvert' can be used to eliminate
 the failed image and proceed.
 
 Mirror resynchronization errors:
@@ -191,11 +191,11 @@ command are set in the LVM configuration file.  They are:
   3-way mirror fails, the mirror will be converted to a 2-way mirror.
   The "allocate" policy takes the further action of trying to replace
   the failed image using space that is available in the volume group.
-  Replacing a failed mirror image will incure the cost of
+  Replacing a failed mirror image will incur the cost of
   resynchronizing - degrading the performance of the mirror.  The
   default policy for handling an image failure is "remove".  This
   allows the mirror to still function, but gives the administrator the
-  choice of when to incure the extra performance costs of replacing
+  choice of when to incur the extra performance costs of replacing
   the failed image.
 
 RAID logical volume device failures are handled differently from the "mirror"
diff --git a/doc/lvmpolld_overview.txt b/doc/lvmpolld_overview.txt
index 8c66e5e1a..ecff2eb81 100644
--- a/doc/lvmpolld_overview.txt
+++ b/doc/lvmpolld_overview.txt
@@ -63,7 +63,7 @@ classical snapshot merge, thin snapshot merge.
 
 The second store is suited only for pvmove --abort operations in-progress. Both
 stores are independent and identical LVs (pvmove /dev/sda3 and pvmove --abort /dev/sda3)
-can be run concurently from lvmpolld point of view (on lvm2 side the consistency is
+can be run concurrently from lvmpolld point of view (on lvm2 side the consistency is
 guaranteed by lvm2 locking mechanism).
 
 Locking order
diff --git a/doc/tagging.txt b/doc/tagging.txt
index b66e0ecd3..95ee02d83 100644
--- a/doc/tagging.txt
+++ b/doc/tagging.txt
@@ -126,7 +126,7 @@ Usage Examples
   followed by 'vgchange -ay vg2'
   
   
-  Option (ii) - localised admin & configuation
+  Option (ii) - localised admin & configuration
   (i.e. each host holds *locally* which classes of volumes to activate)
     # Add @database tag to vg1's metadata
     vgchange --addtag @database vg1
diff --git a/doc/udev_assembly.txt b/doc/udev_assembly.txt
index 618640273..45af41209 100644
--- a/doc/udev_assembly.txt
+++ b/doc/udev_assembly.txt
@@ -35,7 +35,7 @@ VGs from PVs as they appear, and at the same time collect information on what is
 already available. A command, pvscan --cache is expected to be used to
 implement udev rules. It is relatively easy to make this command print out a
 list of VGs (and possibly LVs) that have been made available by adding any
-particular device to the set of visible devices. In othe words, udev says "hey,
+particular device to the set of visible devices. In other words, udev says "hey,
 /dev/sdb just appeared", calls pvscan --cache, which talks to lvmetad, which
 says "cool, that makes vg0 complete". Pvscan takes this info and prints it out,
 and the udev rule can then somehow decide whether anything needs to be done