From: John Garry <john.g.garry@oracle.com>
To: Mike Snitzer <snitzer@hammerspace.com>
Cc: axboe@kernel.dk, agk@redhat.com, hch@lst.de, mpatocka@redhat.com,
martin.petersen@oracle.com, linux-block@vger.kernel.org,
dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 3/5] dm-table: Atomic writes support
Date: Mon, 6 Jan 2025 18:18:23 +0000 [thread overview]
Message-ID: <8f759a68-22fd-430d-85b9-743d4025ecbc@oracle.com> (raw)
In-Reply-To: <Z3wXoytvSU96ZAHj@hammerspace.com>
On 06/01/2025 17:49, Mike Snitzer wrote:
>> +++ b/drivers/md/dm-table.c
>> @@ -1593,6 +1593,7 @@ int dm_calculate_queue_limits(struct dm_table *t,
>> struct queue_limits ti_limits;
>> unsigned int zone_sectors = 0;
>> bool zoned = false;
>> + bool atomic_writes = true;
>>
>> dm_set_stacking_limits(limits);
>>
>> @@ -1602,8 +1603,12 @@ int dm_calculate_queue_limits(struct dm_table *t,
>>
>> if (!dm_target_passes_integrity(ti->type))
>> t->integrity_supported = false;
>> + if (!dm_target_supports_atomic_writes(ti->type))
>> + atomic_writes = false;
>> }
>>
>> + if (atomic_writes)
>> + limits->features |= BLK_FEAT_ATOMIC_WRITES_STACKED;
>> for (unsigned int i = 0; i < t->num_targets; i++) {
>> struct dm_target *ti = dm_table_get_target(t, i);
>>
>> @@ -1616,6 +1621,13 @@ int dm_calculate_queue_limits(struct dm_table *t,
>> goto combine_limits;
>> }
>>
>> + /*
>> + * dm_set_device_limits() -> blk_stack_limits() considers
>> + * ti_limits as 'top', so set BLK_FEAT_ATOMIC_WRITES_STACKED
>> + * here also.
>> + */
>> + if (atomic_writes)
>> + ti_limits.features |= BLK_FEAT_ATOMIC_WRITES_STACKED;
>> /*
>> * Combine queue limits of all the devices this target uses.
>> */
> You're referring to this code that immediately follows this ^ comment
> which stacks up the limits of a target's potential to have N component
> data devices:
>
> ti->type->iterate_devices(ti, dm_set_device_limits,
> &ti_limits);
>
> Your comment and redundant feature flag setting is feels wrong. I'd
> expect code comparable to what is done for zoned, e.g.:
>
> if (!zoned && (ti_limits.features & BLK_FEAT_ZONED)) {
> /*
> * After stacking all limits, validate all devices
> * in table support this zoned model and zone sectors.
> */
> zoned = (ti_limits.features & BLK_FEAT_ZONED);
> zone_sectors = ti_limits.chunk_sectors;
> }
>
> Meaning, for zoned devices, a side-effect of the
> ti->type->iterate_devices() call (and N blk_stack_limits calls) is
> ti_limits.features having BLK_FEAT_ZONED enabled. Why wouldn't the same
> side-effect happen for BLK_FEAT_ATOMIC_WRITES_STACKED (speaks to
> blk_stack_limits being different/wrong for atomic writes support)?
ok, do I admit that my code did not feel quite right, so I will check
the zoned code as a reference.
>
> Just feels not quite right... but I could be wrong, please see if
> there is any "there" there
Will do.
Cheers,
John
next prev parent reply other threads:[~2025-01-06 18:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 12:41 [PATCH RFC 0/5] device mapper atomic write support John Garry
2025-01-06 12:41 ` [PATCH 1/5] block: Ensure start sector is aligned for stacking atomic writes John Garry
2025-01-06 15:36 ` Christoph Hellwig
2025-01-06 12:41 ` [PATCH RFC 2/5] block: Change blk_stack_atomic_writes_limits() unit_min check John Garry
2025-01-06 15:37 ` Christoph Hellwig
2025-01-06 12:41 ` [PATCH RFC 3/5] dm-table: Atomic writes support John Garry
2025-01-06 17:49 ` Mike Snitzer
2025-01-06 18:18 ` John Garry [this message]
2025-01-06 12:41 ` [PATCH RFC 4/5] dm: Ensure cloned bio is same length for atomic write John Garry
2025-01-06 12:41 ` [PATCH RFC 5/5] dm-linear: Enable atomic writes John Garry
2025-01-06 17:26 ` [PATCH RFC 0/5] device mapper atomic write support Mike Snitzer
2025-01-06 18:14 ` John Garry
2025-01-07 17:13 ` Mikulas Patocka
2025-01-07 17:58 ` John Garry
2025-01-07 18:56 ` Mikulas Patocka
2025-01-16 11:28 ` John Garry
2025-01-16 12:59 ` Mikulas Patocka
2025-01-16 13:03 ` John Garry
2025-01-16 14:58 ` Mikulas Patocka
2025-01-16 15:01 ` John Garry
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=8f759a68-22fd-430d-85b9-743d4025ecbc@oracle.com \
--to=john.g.garry@oracle.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mpatocka@redhat.com \
--cc=snitzer@hammerspace.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®