Re: [PATCH] overlayfs.rst: fix typos

[Amir Goldstein <amir73il@gmail.com>]

On Thu, Jul 10, 2025 at 7:06 AM Matthias Frank <frank.mt125@gmail.com> wrote:
>
> Grammatical fixes
>
> Signed-off-by: Matthias Frank <frank.mt125@gmail.com>
> Acked-by: Amir Goldstein <amir73il@gmail.com>

Hi Matthias,

Thanks for making overlayfs.rst better!

Since my ACK was given off-list, I reaffirm it publicly.

Jon,

Can you please pick up this patch?

Thanks,
Amir.

> ---
>  Documentation/filesystems/overlayfs.rst | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
> index 4133a336486d..6e0c572d33dc 100644
> --- a/Documentation/filesystems/overlayfs.rst
> +++ b/Documentation/filesystems/overlayfs.rst
> @@ -9,7 +9,7 @@ Overlay Filesystem
>  This document describes a prototype for a new approach to providing
>  overlay-filesystem functionality in Linux (sometimes referred to as
>  union-filesystems).  An overlay-filesystem tries to present a
> -filesystem which is the result over overlaying one filesystem on top
> +filesystem which is the result of overlaying one filesystem on top
>  of the other.
>
>
> @@ -425,7 +425,7 @@ of information from up to three different layers:
>  The "lower data" file can be on any lower layer, except from the top most
>  lower layer.
>
> -Below the top most lower layer, any number of lower most layers may be defined
> +Below the topmost lower layer, any number of lowermost layers may be defined
>  as "data-only" lower layers, using double colon ("::") separators.
>  A normal lower layer is not allowed to be below a data-only layer, so single
>  colon separators are not allowed to the right of double colon ("::") separators.
> @@ -445,8 +445,8 @@ to the absolute path of the "lower data" file in the "data-only" lower layer.
>
>  Instead of explicitly enabling "metacopy=on" it is sufficient to specify at
>  least one data-only layer to enable redirection of data to a data-only layer.
> -In this case other forms of metacopy are rejected.  Note: this way data-only
> -layers may be used toghether with "userxattr", in which case careful attention
> +In this case other forms of metacopy are rejected.  Note: this way, data-only
> +layers may be used together with "userxattr", in which case careful attention
>  must be given to privileges needed to change the "user.overlay.redirect" xattr
>  to prevent misuse.
>
> @@ -515,7 +515,7 @@ supports these values:
>      The metacopy digest is never generated or used. This is the
>      default if verity option is not specified.
>  - "on":
> -    Whenever a metacopy files specifies an expected digest, the
> +    Whenever a metacopy file specifies an expected digest, the
>      corresponding data file must match the specified digest. When
>      generating a metacopy file the verity digest will be set in it
>      based on the source file (if it has one).
> @@ -537,7 +537,7 @@ Using an upper layer path and/or a workdir path that are already used by
>  another overlay mount is not allowed and may fail with EBUSY.  Using
>  partially overlapping paths is not allowed and may fail with EBUSY.
>  If files are accessed from two overlayfs mounts which share or overlap the
> -upper layer and/or workdir path the behavior of the overlay is undefined,
> +upper layer and/or workdir path, the behavior of the overlay is undefined,
>  though it will not result in a crash or deadlock.
>
>  Mounting an overlay using an upper layer path, where the upper layer path
> @@ -778,7 +778,7 @@ controlled by the "uuid" mount option, which supports these values:
>  - "auto": (default)
>      UUID is taken from xattr "trusted.overlay.uuid" if it exists.
>      Upgrade to "uuid=on" on first time mount of new overlay filesystem that
> -    meets the prerequites.
> +    meets the prerequisites.
>      Downgrade to "uuid=null" for existing overlay filesystems that were never
>      mounted with "uuid=on".
>
> @@ -794,20 +794,20 @@ without significant effort.
>  The advantage of mounting with the "volatile" option is that all forms of
>  sync calls to the upper filesystem are omitted.
>
> -In order to avoid a giving a false sense of safety, the syncfs (and fsync)
> +In order to avoid giving a false sense of safety, the syncfs (and fsync)
>  semantics of volatile mounts are slightly different than that of the rest of
>  VFS.  If any writeback error occurs on the upperdir's filesystem after a
>  volatile mount takes place, all sync functions will return an error.  Once this
>  condition is reached, the filesystem will not recover, and every subsequent sync
> -call will return an error, even if the upperdir has not experience a new error
> +call will return an error, even if the upperdir has not experienced a new error
>  since the last sync call.
>
>  When overlay is mounted with "volatile" option, the directory
>  "$workdir/work/incompat/volatile" is created.  During next mount, overlay
>  checks for this directory and refuses to mount if present. This is a strong
> -indicator that user should throw away upper and work directories and create
> -fresh one. In very limited cases where the user knows that the system has
> -not crashed and contents of upperdir are intact, The "volatile" directory
> +indicator that the user should discard upper and work directories and create
> +fresh ones. In very limited cases where the user knows that the system has
> +not crashed and contents of upperdir are intact, the "volatile" directory
>  can be removed.
>
>
> --
> 2.39.5 (Apple Git-154)
>