* [PATCH] overlayfs.rst: fix typos
@ 2025-07-10 5:06 Matthias Frank
2025-07-10 9:28 ` Amir Goldstein
0 siblings, 1 reply; 3+ messages in thread
From: Matthias Frank @ 2025-07-10 5:06 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc
Cc: Miklos Szeredi, Amir Goldstein, linux-unionfs, Matthias Frank
Grammatical fixes
Signed-off-by: Matthias Frank <frank.mt125@gmail.com>
Acked-by: Amir Goldstein <amir73il@gmail.com>
---
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)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] overlayfs.rst: fix typos
2025-07-10 5:06 [PATCH] overlayfs.rst: fix typos Matthias Frank
@ 2025-07-10 9:28 ` Amir Goldstein
2025-07-15 19:56 ` Jonathan Corbet
0 siblings, 1 reply; 3+ messages in thread
From: Amir Goldstein @ 2025-07-10 9:28 UTC (permalink / raw)
To: Matthias Frank; +Cc: Jonathan Corbet, linux-doc, Miklos Szeredi, linux-unionfs
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)
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] overlayfs.rst: fix typos
2025-07-10 9:28 ` Amir Goldstein
@ 2025-07-15 19:56 ` Jonathan Corbet
0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Corbet @ 2025-07-15 19:56 UTC (permalink / raw)
To: Amir Goldstein, Matthias Frank; +Cc: linux-doc, Miklos Szeredi, linux-unionfs
Amir Goldstein <amir73il@gmail.com> writes:
> 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?
Done.
Thanks,
jon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-15 19:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-10 5:06 [PATCH] overlayfs.rst: fix typos Matthias Frank
2025-07-10 9:28 ` Amir Goldstein
2025-07-15 19:56 ` Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).