From 26a6c69a878abbd829c722e9f5f65aa842d0c1a9 Mon Sep 17 00:00:00 2001 From: Zdenek Kabelac Date: Thu, 29 Aug 2024 23:30:33 +0200 Subject: [PATCH] cleanup: typos in doc --- doc/kernel/persistent-data.txt | 2 +- doc/kernel/zoned.txt | 2 +- doc/lvm_fault_handling.txt | 2 +- doc/lvmetad_design.txt | 4 ++-- doc/refactoring.txt | 4 ++-- doc/release-notes/template.mdwn | 2 +- doc/testing.txt | 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/kernel/persistent-data.txt b/doc/kernel/persistent-data.txt index a333bcb3a..8341f2955 100644 --- a/doc/kernel/persistent-data.txt +++ b/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. diff --git a/doc/kernel/zoned.txt b/doc/kernel/zoned.txt index 736fcc78d..98edb51bd 100644 --- a/doc/kernel/zoned.txt +++ b/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 diff --git a/doc/lvm_fault_handling.txt b/doc/lvm_fault_handling.txt index 196b782db..993e1ed79 100644 --- a/doc/lvm_fault_handling.txt +++ b/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. diff --git a/doc/lvmetad_design.txt b/doc/lvmetad_design.txt index 1961cfbd8..cafdfa0ea 100644 --- a/doc/lvmetad_design.txt +++ b/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 diff --git a/doc/refactoring.txt b/doc/refactoring.txt index 2e9df21fc..3a5023cbf 100644 --- a/doc/refactoring.txt +++ b/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. diff --git a/doc/release-notes/template.mdwn b/doc/release-notes/template.mdwn index 397935b8d..eb6fecc22 100644 --- a/doc/release-notes/template.mdwn +++ b/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 diff --git a/doc/testing.txt b/doc/testing.txt index 214435a7a..0109c9be3 100644 --- a/doc/testing.txt +++ b/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