Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

Documentation: Fix filesystems typos

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

authored by

Bjorn Helgaas and committed by
Jonathan Corbet
81fd803b 8900f9ad

+6 -6
+1 -1
Documentation/filesystems/erofs.rst
··· 116 116 cluster for further reading. It still does 117 117 in-place I/O decompression for the rest 118 118 compressed physical clusters; 119 - readaround Cache the both ends of incomplete compressed 119 + readaround Cache both ends of incomplete compressed 120 120 physical clusters for further reading. 121 121 It still does in-place I/O decompression 122 122 for the rest compressed physical clusters.
+1 -1
Documentation/filesystems/gfs2-glocks.rst
··· 105 105 Operations must not drop either the bit lock or the spinlock 106 106 if its held on entry. go_dump and do_demote_ok must never block. 107 107 Note that go_dump will only be called if the glock's state 108 - indicates that it is caching uptodate data. 108 + indicates that it is caching up-to-date data. 109 109 110 110 Glock locking order within GFS2: 111 111
+1 -1
Documentation/filesystems/hpfs.rst
··· 65 65 'cat FOO', 'cat Foo', 'cat foo' or 'cat F*' but not 'cat f*'. Note, that you 66 66 also won't be able to compile linux kernel (and maybe other things) on HPFS 67 67 because kernel creates different files with names like bootsect.S and 68 - bootsect.s. When searching for file thats name has characters >= 128, codepages 68 + bootsect.s. When searching for file whose name has characters >= 128, codepages 69 69 are used - see below. 70 70 OS/2 ignores dots and spaces at the end of file name, so this driver does as 71 71 well. If you create 'a. ...', the file 'a' will be created, but you can still
+1 -1
Documentation/filesystems/resctrl.rst
··· 563 563 depending on # of threads: 564 564 565 565 For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4 566 - thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although 566 + thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although 567 567 they have same percentage bandwidth of 10%. This is simply because as 568 568 threads start using more cores in an rdtgroup, the actual bandwidth may 569 569 increase or vary although user specified bandwidth percentage is same.
+2 -2
Documentation/filesystems/xfs/xfs-online-fsck-design.rst
··· 454 454 information. 455 455 Once the scan is done, the owning object is re-locked, the live data is used to 456 456 write a new ondisk structure, and the repairs are committed atomically. 457 - The hooks are disabled and the staging staging area is freed. 457 + The hooks are disabled and the staging area is freed. 458 458 Finally, the storage from the old data structure are carefully reaped. 459 459 460 460 Introducing concurrency helps online repair avoid various locking problems, but ··· 2185 2185 checking and repairing of secondary metadata commonly requires coordination 2186 2186 between a live metadata scan of the filesystem and writer threads that are 2187 2187 updating that metadata. 2188 - Keeping the scan data up to date requires requires the ability to propagate 2188 + Keeping the scan data up to date requires the ability to propagate 2189 2189 metadata updates from the filesystem into the data being collected by the scan. 2190 2190 This *can* be done by appending concurrent updates into a separate log file and 2191 2191 applying them before writing the new metadata to disk, but this leads to