From: Mike Snitzer <snitzer@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: dm-devel@lists.linux.dev, Christoph Hellwig <hch@lst.de>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>,
Naohiro Aota <naohiro.aota@wdc.com>
Subject: Re: [PATCH v3] dm: error: Add support for zoned block devices
Date: Fri, 27 Oct 2023 15:08:01 -0400 [thread overview]
Message-ID: <ZTwKkV9aphjYBfIj@redhat.com> (raw)
In-Reply-To: <20231026051205.95209-1-dlemoal@kernel.org>
On Thu, Oct 26 2023 at 1:12P -0400,
Damien Le Moal <dlemoal@kernel.org> wrote:
> dm-error is used in several test cases in the xfstests test suite to
> check the handling of IO errors in file systems. However, with several
> file systems getting native support for zoned block devices (e.g. btrfs
> and f2fs), dm-error lack of zoned block device support creates problems
> as the file system attempt executing zone commands (e.g. a zone append
> operation) against a dm-error non-zoned block device, which causes
> various issues in the block layer (e.g. WARN_ON triggers).
>
> This patch adds supports for zoned block devices to dm-error, allowing
> an md device table containing an error target to be exposed as a zoned
> block device (if all targets have a compatible zoned model support and
> mapping). This is done as follows:
> 1) Allow passing 2 arguments to an error target, similarly to dm-linear:
> a backing device and a start sector. These arguments are optional and
> dm-error retains its characteristics if the arguments are not
> specified.
> 2) Implement the iterate_devices method so that dm-core can normally
> check the zone support and restrictions (e.g. zone alignment of the
> targets). When the backing device arguments are not specified, the
> iterate_devices method never calls the fn() argument.
> When no backing device is specified, as before, we assume that the DM
> device is not zoned. When the backing devie arguments are specified, the
> zoned model of the DM device will depend on the backing device type:
> - If the backing device is zoned and its model and mapping is
> compatible with other targets of the device, the resulting device
> will be zoned, with the dm-error mapped portion always returning
> errors (similarly to the default non-zoned case).
> - If the backing devie is not zoned, then the DM device will not be
> either.
>
> This zone support for dm-error requires the definition of a functional
> report_zones operation so that dm_revalidate_zones() can operate
> correctly and resources for emulating zone append operations
> initialized. This is necessary for cases where dm-error is used to
> partially map a device and have an overall correct handling of zone
> append. This means that dm-error does not fail report zones operations.
>
> Two changes that are not obvious are included to avoid issues:
> 1) dm_table_supports_zoned_model() is changed to directly check if
> the backing device of a wildcard target (= dm-error target) is zoned.
> Otherwise, when the invalid setup of dm-error being set without a
> backing device (non zoned case) and combined with zoned targets
> cannot be cought.
> 2) dm_table_supports_dax() is modified to return false if the wildcard
> target is found. Otherwise, when dm-error is set without a backing
> device, we end up with a NULL pointer dereference in
> set_dax_synchronous dax_dev is NULL. This is consistent with the
> current behavior because dm_table_supports_dax() always returned fals
> for targets that do not define the iterate_devices method.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
I've picked this up. But fixed various typos and such in the commit header.
Also some typos in code comments and bumped the target version to 1.7.
Please see: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-6.7&id=c85b4fb8b8edbd915283f6ab3537f2c3b95e7c85
Thanks,
Mike
next prev parent reply other threads:[~2023-10-27 19:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 5:12 [PATCH v3] dm: error: Add support for zoned block devices Damien Le Moal
2023-10-26 10:55 ` Christoph Hellwig
2023-10-27 19:08 ` Mike Snitzer [this message]
2023-10-29 23:55 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTwKkV9aphjYBfIj@redhat.com \
--to=snitzer@kernel.org \
--cc=dlemoal@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=naohiro.aota@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.