[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ced0f91b-6db7-df23-3988-b687b8beefcc@redhat.com>
Date: Mon, 19 Aug 2024 22:29:58 +0200 (CEST)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Piotr Zalewski <pZ010001011111@...ton.me>
cc: agk@...hat.com, snitzer@...nel.org, corbet@....net,
dm-devel@...ts.linux.dev, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] Documentation: admin-guide/dm: Fix indentation bug
On Mon, 19 Aug 2024, Piotr Zalewski wrote:
> The following bug was found at `admin-guide/device-mapper/dm-crypt.rst`:
> ```
> admin-guide/device-mapper/dm-crypt.rst:167: ERROR: Unexpected indentation.
> ```
> Fix the indentation error.
Hi
This should be already fixed in v6.11-rc4.
Mikulas
> Reviewed-by: Shuah Khan <skhan@...uxfoundation.org>
> Signed-off-by: Piotr Zalewski <pZ010001011111@...ton.me>
> ---
> .../admin-guide/device-mapper/dm-crypt.rst | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst
> index e625830d335e..450c211534a9 100644
> --- a/Documentation/admin-guide/device-mapper/dm-crypt.rst
> +++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst
> @@ -160,15 +160,15 @@ iv_large_sectors
> The <iv_offset> must be multiple of <sector_size> (in 512 bytes units)
> if this flag is specified.
>
> -
> -Module parameters::
> -max_read_size
> -max_write_size
> - Maximum size of read or write requests. When a request larger than this size
> - is received, dm-crypt will split the request. The splitting improves
> - concurrency (the split requests could be encrypted in parallel by multiple
> - cores), but it also causes overhead. The user should tune these parameters to
> - fit the actual workload.
> + Module parameters::
> +
> + max_read_size
> + max_write_size
> + Maximum size of read or write requests. When a request larger than this size
> + is received, dm-crypt will split the request. The splitting improves
> + concurrency (the split requests could be encrypted in parallel by multiple
> + cores), but it also causes overhead. The user should tune these parameters to
> + fit the actual workload.
>
>
> Example scripts
> --
> 2.46.0
>
>
Powered by blists - more mailing lists