From aec5e573afe610070eb2c6bed675d2a7c0efc7e8 Mon Sep 17 00:00:00 2001 From: Samanta Navarro Date: Fri, 30 Dec 2022 11:52:49 +0000 Subject: doc: fix typos in documentation Typos found with codespell. --- doc/kernel/cache-policies.txt | 2 +- doc/kernel/crypt.txt | 4 ++-- doc/kernel/integrity.txt | 2 +- doc/kernel/verity.txt | 2 +- doc/lvm2-raid.txt | 10 +++++----- doc/lvm_fault_handling.txt | 10 +++++----- doc/lvmpolld_overview.txt | 2 +- doc/tagging.txt | 2 +- doc/udev_assembly.txt | 2 +- 9 files changed, 18 insertions(+), 18 deletions(-) (limited to 'doc') 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: \ 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 used for encryption. It is encoded either as a hexadecimal number @@ -81,7 +81,7 @@ 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/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 -- cgit v1.2.1