linux-kernel - Re: [PATCH 2/2] md/bitmap: Add chunk-count-based bitmap flushing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPhsuW6Ur8ic_u3nj9-TSpZ96jWqBa3GLEnw207sN8eJECYwZg@mail.gmail.com>
Date:   Fri, 7 Oct 2022 10:50:35 -0700
From:   Song Liu <song@...nel.org>
To:     Jonathan Derrick <jonathan.derrick@...ux.dev>
Cc:     linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
        jonathan.derrick@...idigm.com, jonathanx.sk.derrick@...el.com
Subject: Re: [PATCH 2/2] md/bitmap: Add chunk-count-based bitmap flushing

On Thu, Oct 6, 2022 at 3:09 PM Jonathan Derrick
<jonathan.derrick@...ux.dev> wrote:

[...]

> diff --git a/drivers/md/md-bitmap.h b/drivers/md/md-bitmap.h
> index cfd7395de8fd..e0aeedbdde17 100644
> --- a/drivers/md/md-bitmap.h
> +++ b/drivers/md/md-bitmap.h
> @@ -11,10 +11,12 @@
>  /* version 4 insists the bitmap is in little-endian order
>   * with version 3, it is host-endian which is non-portable
>   * Version 5 is currently set only for clustered devices
> ++ * Version 6 supports the flush-chunks threshold
>   */
>  #define BITMAP_MAJOR_HI 4
>  #define BITMAP_MAJOR_CLUSTERED 5
>  #define        BITMAP_MAJOR_HOSTENDIAN 3
> +#define BITMAP_MAJOR_CHUNKFLUSH 6
>
>  /*
>   * in-memory bitmap:
> @@ -135,7 +137,8 @@ typedef struct bitmap_super_s {
>                                   * reserved for the bitmap. */
>         __le32 nodes;        /* 68 the maximum number of nodes in cluster. */
>         __u8 cluster_name[64]; /* 72 cluster name to which this md belongs */
> -       __u8  pad[256 - 136]; /* set to zero */
> +       __le32 daemon_flush_chunks; /* 136 dirty chunks between flushes */
> +       __u8  pad[256 - 140]; /* set to zero */
>  } bitmap_super_t;

Do we really need this to be persistent? How about we configure it at run
time via a sysfs file?

Also, please share more data on the performance benefit of the set.

Thanks,
Song

>
>  /* notes:
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index b4e2d8b87b61..d25574e46283 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -497,6 +497,7 @@ struct mddev {
>                 struct mutex            mutex;
>                 unsigned long           chunksize;
>                 unsigned long           daemon_sleep; /* how many jiffies between updates? */
> +               unsigned int            daemon_flush_chunks; /* how many dirty chunks between updates */
>                 unsigned long           max_write_behind; /* write-behind mode */
>                 int                     external;
>                 int                     nodes; /* Maximum number of nodes in the cluster */
> --
> 2.31.1
>