[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87zfg8uxvk.fsf@trenco.lwn.net>
Date: Tue, 22 Apr 2025 07:30:39 -0600
From: Jonathan Corbet <corbet@....net>
To: I Hsin Cheng <richard120310@...il.com>, tytso@....edu
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
skhan@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev, I Hsin
Cheng <richard120310@...il.com>
Subject: Re: [PATCH] docs: ext4: Ammend white space
I Hsin Cheng <richard120310@...il.com> writes:
> There should be a white space between the words "block" and "size",
> instead of writing them together as "blocksize". Ammend a white space
> between them.
>
> Signed-off-by: I Hsin Cheng <richard120310@...il.com>
> ---
> Documentation/filesystems/ext4/blockgroup.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst
> index ed5a5cac6d40..32a66a956f31 100644
> --- a/Documentation/filesystems/ext4/blockgroup.rst
> +++ b/Documentation/filesystems/ext4/blockgroup.rst
> @@ -108,7 +108,7 @@ block groups which can be described by a single block group descriptor
> block. Since the size of the block group descriptor structure is 64
> bytes, a meta-block group contains 16 block groups for filesystems with
> a 1KB block size, and 64 block groups for filesystems with a 4KB
> -blocksize. Filesystems can either be created using this new block group
> +block size. Filesystems can either be created using this new block group
> descriptor layout, or existing filesystems can be resized on-line, and
> the field s_first_meta_bg in the superblock will indicate the first
> block group using this new layout.
Thank you for working to improve the documentation!
If you dig through our documentation, you will see that "blocksize" is
fairly common usage. Changing them all will result in a fair amount of
churn without much in the way of benefit in either readability or
accuracy. May I politely suggest focusing on the many real problems our
documentation has instead?
Thanks,
jon
Powered by blists - more mailing lists