]> git.ipfire.org Git - thirdparty/linux.git/commitdiff
Documentation: Fix filesystems typos
authorBjorn Helgaas <bhelgaas@google.com>
Wed, 13 Aug 2025 20:05:01 +0000 (15:05 -0500)
committerJonathan Corbet <corbet@lwn.net>
Mon, 18 Aug 2025 16:31:19 +0000 (10:31 -0600)
Fix typos.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250813200526.290420-6-helgaas@kernel.org
Documentation/filesystems/erofs.rst
Documentation/filesystems/gfs2-glocks.rst
Documentation/filesystems/hpfs.rst
Documentation/filesystems/resctrl.rst
Documentation/filesystems/xfs/xfs-online-fsck-design.rst

index 7ddb235aee9d4e2678f3062e2094d43f2e5bbb2f..08194f194b9424af9ca6d61a88be0eaea1ded78c 100644 (file)
@@ -116,7 +116,7 @@ cache_strategy=%s      Select a strategy for cached decompression from now on:
                                    cluster for further reading. It still does
                                    in-place I/O decompression for the rest
                                    compressed physical clusters;
-                       readaround  Cache the both ends of incomplete compressed
+                       readaround  Cache both ends of incomplete compressed
                                    physical clusters for further reading.
                                    It still does in-place I/O decompression
                                    for the rest compressed physical clusters.
index adc0d4c4d9798fa0725757e5dff752c1a98f09d8..ce5ff08cbd593d1af1943c8a4b17b3a925e05414 100644 (file)
@@ -105,7 +105,7 @@ go_unlocked           Yes                       No
    Operations must not drop either the bit lock or the spinlock
    if its held on entry. go_dump and do_demote_ok must never block.
    Note that go_dump will only be called if the glock's state
-   indicates that it is caching uptodate data.
+   indicates that it is caching up-to-date data.
 
 Glock locking order within GFS2:
 
index 7e0dd2f4373eb24f804724a09d4d6d4ce6fc3883..0f9516b5eb0793115740cf1a6f9f9f506b900027 100644 (file)
@@ -65,7 +65,7 @@ are case sensitive, so for example when you create a file FOO, you can use
 'cat FOO', 'cat Foo', 'cat foo' or 'cat F*' but not 'cat f*'. Note, that you
 also won't be able to compile linux kernel (and maybe other things) on HPFS
 because kernel creates different files with names like bootsect.S and
-bootsect.s. When searching for file thats name has characters >= 128, codepages
+bootsect.s. When searching for file whose name has characters >= 128, codepages
 are used - see below.
 OS/2 ignores dots and spaces at the end of file name, so this driver does as
 well. If you create 'a. ...', the file 'a' will be created, but you can still
index c7949dd44f2f3aa007e11a565cf4b1baaaaba9e0..4db3b07c16c53c411cd96b946342f6515ff1d78c 100644 (file)
@@ -563,7 +563,7 @@ this would be dependent on number of cores the benchmark is run on.
    depending on # of threads:
 
 For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
-thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
+thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
 they have same percentage bandwidth of 10%. This is simply because as
 threads start using more cores in an rdtgroup, the actual bandwidth may
 increase or vary although user specified bandwidth percentage is same.
index e231d127cd4054ee46ed875dd834bbb91cfa5ae9..9fe994353395848eacd3c07f6e6ce67db4680545 100644 (file)
@@ -454,7 +454,7 @@ filesystem so that it can apply pending filesystem updates to the staging
 information.
 Once the scan is done, the owning object is re-locked, the live data is used to
 write a new ondisk structure, and the repairs are committed atomically.
-The hooks are disabled and the staging staging area is freed.
+The hooks are disabled and the staging area is freed.
 Finally, the storage from the old data structure are carefully reaped.
 
 Introducing concurrency helps online repair avoid various locking problems, but
@@ -2185,7 +2185,7 @@ The chapter about :ref:`secondary metadata<secondary_metadata>` mentioned that
 checking and repairing of secondary metadata commonly requires coordination
 between a live metadata scan of the filesystem and writer threads that are
 updating that metadata.
-Keeping the scan data up to date requires requires the ability to propagate
+Keeping the scan data up to date requires the ability to propagate
 metadata updates from the filesystem into the data being collected by the scan.
 This *can* be done by appending concurrent updates into a separate log file and
 applying them before writing the new metadata to disk, but this leads to