btrfs-progs: docs: fix typos in documentation

ArturKlauser · kdave · commit fc1c1a266fcc · 2025-03-11T21:38:50.000+01:00
Pull-request: #968 Signed-off-by: David Sterba <dsterba@suse.com>
diff --git a/Documentation/Auto-repair.rst b/Documentation/Auto-repair.rst
@@ -1,7 +1,7 @@
 Auto-repair on read
 ===================
 
-If data or metadata that are found to be damaged at the time they’re read from a device,
+If data or metadata are found to be damaged at the time they’re read from a device,
 for example because the checksum does not match, they can be salvaged if the filesystem
 has another valid copy. This can be achieved by using a block group profile with redundancy
 like DUP, RAID1-like, or RAID5/6.
diff --git a/Documentation/Glossary.rst b/Documentation/Glossary.rst
@@ -118,7 +118,7 @@ DUP
 
 ENOSPC
 	Error code returned by the OS to a user program when the filesystem
-	cannot allocate enough data to fulfill the user requested. In most
+	cannot allocate enough data to fulfill the user request. In most
 	filesystems, it indicates there is no free space available in the
 	filesystem. Due to the additional space requirements from btrfs's
 	*COW* behaviour, btrfs can sometimes return ENOSPC when there is
diff --git a/Documentation/Interoperability.rst b/Documentation/Interoperability.rst
@@ -53,7 +53,7 @@ automatically in any way, must be resolved either in btrfs or on the DM/MD
 layer.
 
 The functionality of DM/MD may duplicate the one provided by btrfs (like
-mirroring), it's possible to use it that way but is probably wasteful and may
+mirroring), it's possible to use it that way but it's probably wasteful and may
 degrade performance. Creating a filesystem on top of the multiplexed device is
 likely the desired way.
 
diff --git a/Documentation/Status.rst b/Documentation/Status.rst
@@ -9,7 +9,7 @@ For a list of features by the kernel version of their introduction, please see
 
 The table below is an overview of the stability status of
 the features that BTRFS supports. While a feature may be functionally safe
-and reliable, it does not necessarily mean that it is meeting
+and reliable, it does not necessarily mean that it is
 suitable for all use cases or workloads, for example performance.
 Combination of features can vary in performance, the table does not
 cover all possibilities.
@@ -480,7 +480,7 @@ Experimental features
 Until kernel 6.12 the *CONFIG_OPTION_DEBUG* was used to hide features that
 still need some work and should not be exposed to users in general. With
 the increasing number of such features or functionality this started to conflict
-with regular debugging features. Currently there the following is behind
+with regular debugging features. Currently the following is behind
 the experimental option. Use with caution and if you find problems or have
 feedback please report that to the mailing list.
 
diff --git a/Documentation/Tree-checker.rst b/Documentation/Tree-checker.rst
@@ -22,7 +22,7 @@ by other parts of the system or hardware errors (namely faulty RAM).
 
 Once a block does not pass the checks, the filesystem refuses to write more data
 and turns itself to read-only mode to prevent further damage. At this point some
-the recent metadata updates are held *only* in memory so it's best to not panic
+of the recent metadata updates are held *only* in memory so it's best to not panic
 and try to remember what files could be affected and copy them elsewhere. Once
 the filesystem gets unmounted, the most recent changes are unfortunately lost.
 The filesystem that is stored on the device is still consistent and should mount
diff --git a/Documentation/Trim.rst b/Documentation/Trim.rst
@@ -7,7 +7,7 @@ of other block device types. On real hardware, there's a different lifetime
 span of the memory cells and the driver firmware usually tries to optimize for
 that. The trim operation issued by user provides hints about what data are
 unused and allow to reclaim the memory cells. On thin-provisioned or emulated
-this is could simply free the space.
+this could simply free the space.
 
 There are three main uses of trim that BTRFS supports:
 
diff --git a/Documentation/ch-volume-management-intro.rst b/Documentation/ch-volume-management-intro.rst
@@ -121,7 +121,7 @@ In order to remove a device, you need to convert the profile in this case:
    Do not run balance to convert from a profile with more redundancy to one with
    less redundancy in order to remove a failing device from a filesystem.
 
-   Balance is done by reading out the good metadata/data and write them into into a
+   Balance is done by reading out the good metadata/data and write them into a
    new chunk.
    Thus it's possible the new chunk is written into the failing device.
 
diff --git a/Documentation/mkfs.btrfs.rst b/Documentation/mkfs.btrfs.rst
@@ -29,7 +29,7 @@ OPTIONS
 
 -b|--byte-count <size>
         Specify the size of each device as seen by the filesystem. If not set,
-        the entire device size is used. The total filesystem size will be sum
+        the entire device size is used. The total filesystem size will be the sum
         of all device sizes, for a single device filesystem the option
         effectively specifies the size of the filesystem.
 
@@ -165,7 +165,7 @@ OPTIONS
 
         It is recommended to use the highest level to achieve maximum space savings.
         Compression at mkfs time is not as constrained as in kernel where it's
-        desirable to use the less CPU load. Otherwise the default level is 3.
+        desirable to use less CPU load. Otherwise the default level is 3.
 
         As with the kernel, :command:`mkfs.btrfs` won't write compressed extents when
         they would be larger than the uncompressed versions, and will set file attribute
