Fix several spelling mistakes in documentation:
- Availablity -> Availability
- heirarchy -> hierarchy
- maping -> mapping
Findings are based on v6.17-rc2.
Signed-off-by: Sahil Chandna <chandna.linuxkernel@xxxxxxxxx>
---
Documentation/admin-guide/cgroup-v2.rst | 2 +-
Documentation/filesystems/bcachefs/future/idle_work.rst | 6 +++---
Documentation/filesystems/xfs/xfs-online-fsck-design.rst | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index d9d3cc7df348..29172f03b863 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -435,7 +435,7 @@ both cgroups.
Controlling Controllers
-----------------------
-Availablity
+Availability
~~~~~~~~~~~
A controller is available in a cgroup when it is supported by the kernel (i.e.,
diff --git a/Documentation/filesystems/bcachefs/future/idle_work.rst b/Documentation/filesystems/bcachefs/future/idle_work.rst
index 59a332509dcd..f1202113dde0 100644
--- a/Documentation/filesystems/bcachefs/future/idle_work.rst
+++ b/Documentation/filesystems/bcachefs/future/idle_work.rst
@@ -11,10 +11,10 @@ idle" so the system can go to sleep. We don't want to be dribbling out
background work while the system should be idle.
The complicating factor is that there are a number of background tasks, which
-form a heirarchy (or a digraph, depending on how you divide it up) - one
+form a hierarchy (or a digraph, depending on how you divide it up) - one
background task may generate work for another.
-Thus proper idle detection needs to model this heirarchy.
+Thus proper idle detection needs to model this hierarchy.
- Foreground writes
- Page cache writeback
@@ -51,7 +51,7 @@ IDLE REGIME
When the system becomes idle, we should start flushing our pending work
quicker so the system can go to sleep.
-Note that the definition of "idle" depends on where in the heirarchy a task
+Note that the definition of "idle" depends on where in the hierarchy a task
is - a task should start flushing work more quickly when the task above it has
stopped generating new work.
diff --git a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
index e231d127cd40..e872d480691b 100644
--- a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
+++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
@@ -4179,7 +4179,7 @@ When the exchange is initiated, the sequence of operations is as follows:
This will be discussed in more detail in subsequent sections.
If the filesystem goes down in the middle of an operation, log recovery will
-find the most recent unfinished maping exchange log intent item and restart
+find the most recent unfinished mapping exchange log intent item and restart
from there.
This is how atomic file mapping exchanges guarantees that an outside observer
will either see the old broken structure or the new one, and never a mismash of
--
2.34.1
