[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YsWIwQ7Z2OKesQVI@infradead.org>
Date: Wed, 6 Jul 2022 06:06:09 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Sergei Shtepa <sergei.shtepa@...am.com>
Cc: axboe@...nel.dk, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 18/20] block, blksnap: Kconfig
On Mon, Jun 13, 2022 at 06:53:11PM +0300, Sergei Shtepa wrote:
> +config BLK_SNAP_TRACKING_BLOCK_MINIMUM_SHIFT
> + depends on BLK_SNAP
> + int "The power of 2 for minimum trackings block size"
> +config BLK_SNAP_TRACKING_BLOCK_MAXIMUM_COUNT
> + depends on BLK_SNAP
> +config BLK_SNAP_CHUNK_MINIMUM_SHIFT
> + depends on BLK_SNAP
> +config BLK_SNAP_CHUNK_MAXIMUM_COUNT
> + depends on BLK_SNAP
> + int "The limit of the maximum number of snapshots chunks"
...
Is there any good reason for these to be compile options vs runtime
settings?
> +config BLK_SNAP_DEBUG_MEMORY_LEAK
> + depends on BLK_SNAP
> + bool "Enable memory leak detector"
> + default n
> + help
> + Enables debugging code to monitor memory consumption by the module.
Is there any advantage in this over kmemleak and friends?
Powered by blists - more mailing lists