On 10/25/23 14:22, Naohiro Aota wrote:
> On Tue, Oct 24, 2023 at 07:45:13AM +0900, Damien Le Moal wrote:
>> dm-error is used in several test cases in the xfstests test suite to
>> check the handling of IO errors in file syatems. However, with several
> ^ systems
>
>> 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 error table to be exposed as a zoned block device. This is done by
>> relying on the first argument passed to dmsetup when creating the device
>> table: if that first argument is a path to a backing block device, the
>> dm-error device is created by copying the limits of the backing device,
>> thus also copying its zone model. This is consistent with how xfstests
>> creates dm-error devices (always passing the path to the backing device
>> as the first argument).
>>
>> The zone support for dm-error requires the definition of the
>> report_zones target type method, which is done by introducing the
>> function io_err_report_zones(). Given that this function fails report
>> zones operations (similarly to any other command issued to the dm-error
>> device), dm_set_zones_restrictions() is tweaked to do nothing for a
>> wildcard target to avoid failing zone revalidation. As the dm-error
>> target does not implemt the iterate_devices method,
> ^implement
Thanks. Will fix that.
>
>> dm_table_supports_zoned_model() is also changed to return true.
>>
>> Signed-off-by: Damien Le Moal
>> ---
>> drivers/md/dm-table.c | 3 +++
>> drivers/md/dm-target.c | 42 --
>> drivers/md/dm-zone.c | 9 +
>> 3 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
>> index 37b48f63ae6a..5e4d887063d3 100644
>> --- a/drivers/md/dm-table.c
>> +++ b/drivers/md/dm-table.c
>> @@ -1600,6 +1600,9 @@ static bool dm_table_supports_zoned_model(struct
>> dm_table *t,
>> for (unsigned int i = 0; i < t->num_targets; i++) {
>> struct dm_target *ti = dm_table_get_target(t, i);
>>
>> +if (dm_target_is_wildcard(ti->type))
>> +continue;
>> +
>
> This seems tricky to me. Currently, dm-error is the only dm target having
> DM_TARGET_WILDCARD. But, can we expect that will be so forever?
Yes, I saw that. Not sure. Mike ?
> Also, I considered what happens if the backing device is non-zoned
> one. dm_table_supports_zoned_model() returns true in that case. But, it is
> still reported as non-zoned as we copy non-zoned queue limits. So, it is
> OK ... but it is a bit tricky.
Returning true for dm_table_supports_zoned_model() is not an issue. As the name
of the function says, this checks that the device table is OK with zoned device
but does not force the dm device to be zoned.
> Instead, how about implementing the .iterate_devices just like
> linear_iterate_devices?
Because that would change how dm-error needs to be setup. Currently, there are
no arguments needed for the table entry for dm-error. If we define the
->iterate_devices operation, we'll need a backing device and mapping start
sector. Changing the dmsetup command line for all users is probably not the best
approach... Unless I am missing something...
>> diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
>> index 27e2992ff249..1bf4ecda3012 100644
>> --- a/drivers/md/dm-target.c
>> +++ b/drivers/md/dm-target.c
>> @@ -118,6 +118,21 @@ EXPORT_SYMBOL(dm_unregister_target);
>> */
>> static int io_err_ctr(struct dm_target *tt, unsigned int argc, char **args)
>> {
>> +struct dm_dev *ddev;
>> +int ret;
>> +
>> +/*
>> + * If we have an argument, assume it is the path to the target
>> + * block device we are replacing. In this case, get the device
>> + * so that we can copy its limits in io_err_io_hints().
>> + */
>> +if (argc) {
>> +ret = dm_get_device(tt, args[0], dm_table_get_mode(tt->table),
>> +);
>> +if (ret == 0)
>> +tt->private = ddev;
>
> No need to handle an error case here? Or, I guess it ignores an error for
> compatibility when non-device argument is specified. Then, I'd like to add
> a note here.
Yes, exactly. Before the change, arguments were ignored. I will add a comment.
--
Damien Le Moal
Western Digital Research
