linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v5 0/5] RAID 0/1/10 atomic write support
@ 2024-11-18 10:50 John Garry
  2024-11-18 10:50 ` [PATCH v5 1/5] block: Add extra checks in blk_validate_atomic_write_limits() John Garry
                   ` (7 more replies)
  0 siblings, 8 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

This series introduces atomic write support for software RAID 0/1/10.

The main changes are to ensure that we can calculate the stacked device
request_queue limits appropriately for atomic writes. Fundamentally, if
some bottom does not support atomic writes, then atomic writes are not
supported for the top device. Furthermore, the atomic writes limits are
the lowest common supported limits from all bottom devices.

Flag BLK_FEAT_ATOMIC_WRITES_STACKED is introduced to enable atomic writes
for stacked devices selectively. This ensures that we can analyze and test
atomic writes support per individual md/dm personality (prior to
enabling).

Based on 88d47f629313 (block/for-6.13/block) Merge tag
'md-6.13-20241115' of https://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux 
into for-6.13/block

Differences to v4:
- Add RB tags from Kuai (thanks!)
- Change error code for atomic write to BB (Song, Kuai)
- Add fuller comment about atomic write to BB (Kuai)

Differences to v3:
- Add RB tags from Christoph and Kuai (thanks!)
- Rebase

Differences to v2:
- Refactor blk_stack_atomic_writes_limits() (Christoph)
- Relocate RAID 1/10 BB check (Kuai)
- Add RB tag from Christoph (Thanks!)
- Set REQ_ATOMIC for RAID 1/10a

John Garry (5):
  block: Add extra checks in blk_validate_atomic_write_limits()
  block: Support atomic writes limits for stacked devices
  md/raid0: Atomic write support
  md/raid1: Atomic write support
  md/raid10: Atomic write support

 block/blk-settings.c   | 132 +++++++++++++++++++++++++++++++++++++++++
 drivers/md/raid0.c     |   1 +
 drivers/md/raid1.c     |  20 ++++++-
 drivers/md/raid10.c    |  20 ++++++-
 include/linux/blkdev.h |   4 ++
 5 files changed, 173 insertions(+), 4 deletions(-)

-- 
2.31.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v5 1/5] block: Add extra checks in blk_validate_atomic_write_limits()
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
@ 2024-11-18 10:50 ` John Garry
  2024-11-18 10:50 ` [PATCH v5 2/5] block: Support atomic writes limits for stacked devices John Garry
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

It is so far expected that the limits passed are valid.

In future atomic writes will be supported for stacked block devices, and
calculating the limits there will be complicated, so add extra sanity
checks to ensure that the values are always valid.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 block/blk-settings.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index f1d4dfdc37a7..cdfebbd5f571 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -178,9 +178,26 @@ static void blk_validate_atomic_write_limits(struct queue_limits *lim)
 	if (!lim->atomic_write_hw_max)
 		goto unsupported;
 
+	if (WARN_ON_ONCE(!is_power_of_2(lim->atomic_write_hw_unit_min)))
+		goto unsupported;
+
+	if (WARN_ON_ONCE(!is_power_of_2(lim->atomic_write_hw_unit_max)))
+		goto unsupported;
+
+	if (WARN_ON_ONCE(lim->atomic_write_hw_unit_min >
+			 lim->atomic_write_hw_unit_max))
+		goto unsupported;
+
+	if (WARN_ON_ONCE(lim->atomic_write_hw_unit_max >
+			 lim->atomic_write_hw_max))
+		goto unsupported;
+
 	boundary_sectors = lim->atomic_write_hw_boundary >> SECTOR_SHIFT;
 
 	if (boundary_sectors) {
+		if (WARN_ON_ONCE(lim->atomic_write_hw_max >
+				 lim->atomic_write_hw_boundary))
+			goto unsupported;
 		/*
 		 * A feature of boundary support is that it disallows bios to
 		 * be merged which would result in a merged request which
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v5 2/5] block: Support atomic writes limits for stacked devices
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
  2024-11-18 10:50 ` [PATCH v5 1/5] block: Add extra checks in blk_validate_atomic_write_limits() John Garry
@ 2024-11-18 10:50 ` John Garry
  2024-11-18 10:50 ` [PATCH v5 3/5] md/raid0: Atomic write support John Garry
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

Allow stacked devices to support atomic writes by aggregating the minimum
capability of all bottom devices.

Flag BLK_FEAT_ATOMIC_WRITES_STACKED is set for stacked devices which
have been enabled to support atomic writes.

Some things to note on the implementation:
- For simplicity, all bottom devices must have same atomic write boundary
  value (if any)
- The atomic write boundary must be a power-of-2 already, but this
  restriction could be relaxed. Furthermore, it is now required that the
  chunk sectors for a top device must be aligned with this boundary.
- If a bottom device atomic write unit min/max are not aligned with the
  top device chunk sectors, the top device atomic write unit min/max are
  reduced to a value which works for the chunk sectors.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 block/blk-settings.c   | 115 +++++++++++++++++++++++++++++++++++++++++
 include/linux/blkdev.h |   4 ++
 2 files changed, 119 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index cdfebbd5f571..f7368c29424c 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -496,6 +496,119 @@ static unsigned int blk_round_down_sectors(unsigned int sectors, unsigned int lb
 	return sectors;
 }
 
+/* Check if second and later bottom devices are compliant */
+static bool blk_stack_atomic_writes_tail(struct queue_limits *t,
+				struct queue_limits *b)
+{
+	/* We're not going to support different boundary sizes.. yet */
+	if (t->atomic_write_hw_boundary != b->atomic_write_hw_boundary)
+		return false;
+
+	/* Can't support this */
+	if (t->atomic_write_hw_unit_min > b->atomic_write_hw_unit_max)
+		return false;
+
+	/* Or this */
+	if (t->atomic_write_hw_unit_max < b->atomic_write_hw_unit_min)
+		return false;
+
+	t->atomic_write_hw_max = min(t->atomic_write_hw_max,
+				b->atomic_write_hw_max);
+	t->atomic_write_hw_unit_min = max(t->atomic_write_hw_unit_min,
+				b->atomic_write_hw_unit_min);
+	t->atomic_write_hw_unit_max = min(t->atomic_write_hw_unit_max,
+				b->atomic_write_hw_unit_max);
+	return true;
+}
+
+/* Check for valid boundary of first bottom device */
+static bool blk_stack_atomic_writes_boundary_head(struct queue_limits *t,
+				struct queue_limits *b)
+{
+	/*
+	 * Ensure atomic write boundary is aligned with chunk sectors. Stacked
+	 * devices store chunk sectors in t->io_min.
+	 */
+	if (b->atomic_write_hw_boundary > t->io_min &&
+	    b->atomic_write_hw_boundary % t->io_min)
+		return false;
+	if (t->io_min > b->atomic_write_hw_boundary &&
+	    t->io_min % b->atomic_write_hw_boundary)
+		return false;
+
+	t->atomic_write_hw_boundary = b->atomic_write_hw_boundary;
+	return true;
+}
+
+
+/* Check stacking of first bottom device */
+static bool blk_stack_atomic_writes_head(struct queue_limits *t,
+				struct queue_limits *b)
+{
+	if (b->atomic_write_hw_boundary &&
+	    !blk_stack_atomic_writes_boundary_head(t, b))
+		return false;
+
+	if (t->io_min <= SECTOR_SIZE) {
+		/* No chunk sectors, so use bottom device values directly */
+		t->atomic_write_hw_unit_max = b->atomic_write_hw_unit_max;
+		t->atomic_write_hw_unit_min = b->atomic_write_hw_unit_min;
+		t->atomic_write_hw_max = b->atomic_write_hw_max;
+		return true;
+	}
+
+	/*
+	 * Find values for limits which work for chunk size.
+	 * b->atomic_write_hw_unit_{min, max} may not be aligned with chunk
+	 * size (t->io_min), as chunk size is not restricted to a power-of-2.
+	 * So we need to find highest power-of-2 which works for the chunk
+	 * size.
+	 * As an example scenario, we could have b->unit_max = 16K and
+	 * t->io_min = 24K. For this case, reduce t->unit_max to a value
+	 * aligned with both limits, i.e. 8K in this example.
+	 */
+	t->atomic_write_hw_unit_max = b->atomic_write_hw_unit_max;
+	while (t->io_min % t->atomic_write_hw_unit_max)
+		t->atomic_write_hw_unit_max /= 2;
+
+	t->atomic_write_hw_unit_min = min(b->atomic_write_hw_unit_min,
+					  t->atomic_write_hw_unit_max);
+	t->atomic_write_hw_max = min(b->atomic_write_hw_max, t->io_min);
+
+	return true;
+}
+
+static void blk_stack_atomic_writes_limits(struct queue_limits *t,
+				struct queue_limits *b)
+{
+	if (!(t->features & BLK_FEAT_ATOMIC_WRITES_STACKED))
+		goto unsupported;
+
+	if (!b->atomic_write_unit_min)
+		goto unsupported;
+
+	/*
+	 * If atomic_write_hw_max is set, we have already stacked 1x bottom
+	 * device, so check for compliance.
+	 */
+	if (t->atomic_write_hw_max) {
+		if (!blk_stack_atomic_writes_tail(t, b))
+			goto unsupported;
+		return;
+	}
+
+	if (!blk_stack_atomic_writes_head(t, b))
+		goto unsupported;
+	return;
+
+unsupported:
+	t->atomic_write_hw_max = 0;
+	t->atomic_write_hw_unit_max = 0;
+	t->atomic_write_hw_unit_min = 0;
+	t->atomic_write_hw_boundary = 0;
+	t->features &= ~BLK_FEAT_ATOMIC_WRITES_STACKED;
+}
+
 /**
  * blk_stack_limits - adjust queue_limits for stacked devices
  * @t:	the stacking driver limits (top device)
@@ -656,6 +769,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
 		t->zone_write_granularity = 0;
 		t->max_zone_append_sectors = 0;
 	}
+	blk_stack_atomic_writes_limits(t, b);
+
 	return ret;
 }
 EXPORT_SYMBOL(blk_stack_limits);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index a1fd0ddce5cf..f4587355bd45 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -333,6 +333,10 @@ typedef unsigned int __bitwise blk_features_t;
 #define BLK_FEAT_RAID_PARTIAL_STRIPES_EXPENSIVE \
 	((__force blk_features_t)(1u << 15))
 
+/* stacked device can/does support atomic writes */
+#define BLK_FEAT_ATOMIC_WRITES_STACKED \
+	((__force blk_features_t)(1u << 16))
+
 /*
  * Flags automatically inherited when stacking limits.
  */
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v5 3/5] md/raid0: Atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
  2024-11-18 10:50 ` [PATCH v5 1/5] block: Add extra checks in blk_validate_atomic_write_limits() John Garry
  2024-11-18 10:50 ` [PATCH v5 2/5] block: Support atomic writes limits for stacked devices John Garry
@ 2024-11-18 10:50 ` John Garry
  2024-11-18 10:50 ` [PATCH v5 4/5] md/raid1: " John Garry
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes. All other
stacked device request queue limits should automatically be set properly.
With regards to atomic write max bytes limit, this will be set at
hw_max_sectors and this is limited by the stripe width, which we want.

Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 drivers/md/raid0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index baaf5f8b80ae..7049ec7fb8eb 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -384,6 +384,7 @@ static int raid0_set_limits(struct mddev *mddev)
 	lim.max_write_zeroes_sectors = mddev->chunk_sectors;
 	lim.io_min = mddev->chunk_sectors << 9;
 	lim.io_opt = lim.io_min * mddev->raid_disks;
+	lim.features |= BLK_FEAT_ATOMIC_WRITES_STACKED;
 	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
 	if (err) {
 		queue_limits_cancel_update(mddev->gendisk->queue);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v5 4/5] md/raid1: Atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
                   ` (2 preceding siblings ...)
  2024-11-18 10:50 ` [PATCH v5 3/5] md/raid0: Atomic write support John Garry
@ 2024-11-18 10:50 ` John Garry
  2024-11-18 10:50 ` [PATCH v5 5/5] md/raid10: " John Garry
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes.

For an attempt to atomic write to a region which has bad blocks, error
the write as we just cannot do this. It is unlikely to find devices which
support atomic writes and bad blocks.

Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 drivers/md/raid1.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index a5adf08ee174..519c56f0ee3d 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1571,7 +1571,21 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
 				continue;
 			}
 			if (is_bad) {
-				int good_sectors = first_bad - r1_bio->sector;
+				int good_sectors;
+
+				/*
+				 * We cannot atomically write this, so just
+				 * error in that case. It could be possible to
+				 * atomically write other mirrors, but the
+				 * complexity of supporting that is not worth
+				 * the benefit.
+				 */
+				if (bio->bi_opf & REQ_ATOMIC) {
+					error = -EIO;
+					goto err_handle;
+				}
+
+				good_sectors = first_bad - r1_bio->sector;
 				if (good_sectors < max_sectors)
 					max_sectors = good_sectors;
 			}
@@ -1657,7 +1671,8 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
 
 		mbio->bi_iter.bi_sector	= (r1_bio->sector + rdev->data_offset);
 		mbio->bi_end_io	= raid1_end_write_request;
-		mbio->bi_opf = bio_op(bio) | (bio->bi_opf & (REQ_SYNC | REQ_FUA));
+		mbio->bi_opf = bio_op(bio) |
+			(bio->bi_opf & (REQ_SYNC | REQ_FUA | REQ_ATOMIC));
 		if (test_bit(FailFast, &rdev->flags) &&
 		    !test_bit(WriteMostly, &rdev->flags) &&
 		    conf->raid_disks - mddev->degraded > 1)
@@ -3224,6 +3239,7 @@ static int raid1_set_limits(struct mddev *mddev)
 
 	md_init_stacking_limits(&lim);
 	lim.max_write_zeroes_sectors = 0;
+	lim.features |= BLK_FEAT_ATOMIC_WRITES_STACKED;
 	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
 	if (err) {
 		queue_limits_cancel_update(mddev->gendisk->queue);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v5 5/5] md/raid10: Atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
                   ` (3 preceding siblings ...)
  2024-11-18 10:50 ` [PATCH v5 4/5] md/raid1: " John Garry
@ 2024-11-18 10:50 ` John Garry
  2024-11-19  1:37 ` [PATCH v5 0/5] RAID 0/1/10 atomic " Martin K. Petersen
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-18 10:50 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen,
	John Garry

Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes.

For an attempt to atomic write to a region which has bad blocks, error
the write as we just cannot do this. It is unlikely to find devices which
support atomic writes and bad blocks.

Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 drivers/md/raid10.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 8c7f5daa073a..f779d8225667 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1255,6 +1255,7 @@ static void raid10_write_one_disk(struct mddev *mddev, struct r10bio *r10_bio,
 	const enum req_op op = bio_op(bio);
 	const blk_opf_t do_sync = bio->bi_opf & REQ_SYNC;
 	const blk_opf_t do_fua = bio->bi_opf & REQ_FUA;
+	const blk_opf_t do_atomic = bio->bi_opf & REQ_ATOMIC;
 	unsigned long flags;
 	struct r10conf *conf = mddev->private;
 	struct md_rdev *rdev;
@@ -1273,7 +1274,7 @@ static void raid10_write_one_disk(struct mddev *mddev, struct r10bio *r10_bio,
 	mbio->bi_iter.bi_sector	= (r10_bio->devs[n_copy].addr +
 				   choose_data_offset(r10_bio, rdev));
 	mbio->bi_end_io	= raid10_end_write_request;
-	mbio->bi_opf = op | do_sync | do_fua;
+	mbio->bi_opf = op | do_sync | do_fua | do_atomic;
 	if (!replacement && test_bit(FailFast,
 				     &conf->mirrors[devnum].rdev->flags)
 			 && enough(conf, devnum))
@@ -1468,7 +1469,21 @@ static void raid10_write_request(struct mddev *mddev, struct bio *bio,
 				continue;
 			}
 			if (is_bad) {
-				int good_sectors = first_bad - dev_sector;
+				int good_sectors;
+
+				/*
+				 * We cannot atomically write this, so just
+				 * error in that case. It could be possible to
+				 * atomically write other mirrors, but the
+				 * complexity of supporting that is not worth
+				 * the benefit.
+				 */
+				if (bio->bi_opf & REQ_ATOMIC) {
+					error = -EIO;
+					goto err_handle;
+				}
+
+				good_sectors = first_bad - dev_sector;
 				if (good_sectors < max_sectors)
 					max_sectors = good_sectors;
 			}
@@ -4025,6 +4040,7 @@ static int raid10_set_queue_limits(struct mddev *mddev)
 	lim.max_write_zeroes_sectors = 0;
 	lim.io_min = mddev->chunk_sectors << 9;
 	lim.io_opt = lim.io_min * raid10_nr_stripes(conf);
+	lim.features |= BLK_FEAT_ATOMIC_WRITES_STACKED;
 	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
 	if (err) {
 		queue_limits_cancel_update(mddev->gendisk->queue);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH v5 0/5] RAID 0/1/10 atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
                   ` (4 preceding siblings ...)
  2024-11-18 10:50 ` [PATCH v5 5/5] md/raid10: " John Garry
@ 2024-11-19  1:37 ` Martin K. Petersen
  2024-11-19 17:05 ` John Garry
  2024-11-19 17:30 ` Jens Axboe
  7 siblings, 0 replies; 11+ messages in thread
From: Martin K. Petersen @ 2024-11-19  1:37 UTC (permalink / raw)
  To: John Garry
  Cc: axboe, song, yukuai3, hch, linux-block, linux-kernel, linux-raid,
	martin.petersen


John,

> This series introduces atomic write support for software RAID 0/1/10.
>
> The main changes are to ensure that we can calculate the stacked
> device request_queue limits appropriately for atomic writes.
> Fundamentally, if some bottom does not support atomic writes, then
> atomic writes are not supported for the top device. Furthermore, the
> atomic writes limits are the lowest common supported limits from all
> bottom devices.
>
> Flag BLK_FEAT_ATOMIC_WRITES_STACKED is introduced to enable atomic
> writes for stacked devices selectively. This ensures that we can
> analyze and test atomic writes support per individual md/dm
> personality (prior to enabling).

LGTM.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v5 0/5] RAID 0/1/10 atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
                   ` (5 preceding siblings ...)
  2024-11-19  1:37 ` [PATCH v5 0/5] RAID 0/1/10 atomic " Martin K. Petersen
@ 2024-11-19 17:05 ` John Garry
  2024-11-19 17:29   ` Jens Axboe
  2024-11-19 17:30 ` Jens Axboe
  7 siblings, 1 reply; 11+ messages in thread
From: John Garry @ 2024-11-19 17:05 UTC (permalink / raw)
  To: axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen

On 18/11/2024 10:50, John Garry wrote:
> This series introduces atomic write support for software RAID 0/1/10.
> 
> The main changes are to ensure that we can calculate the stacked device
> request_queue limits appropriately for atomic writes. Fundamentally, if
> some bottom does not support atomic writes, then atomic writes are not
> supported for the top device. Furthermore, the atomic writes limits are
> the lowest common supported limits from all bottom devices.
> 
> Flag BLK_FEAT_ATOMIC_WRITES_STACKED is introduced to enable atomic writes
> for stacked devices selectively. This ensures that we can analyze and test
> atomic writes support per individual md/dm personality (prior to
> enabling).
> 
> Based on 88d47f629313 (block/for-6.13/block) Merge tag
> 'md-6.13-20241115' ofhttps://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux 
> into for-6.13/block

Hi Jens,

In case you are planning on sending a 2nd batch of new dev for 6.13, I 
think that this is in mergeable state.

If not, I'll repost for 6.14 later.

Thanks,
John

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v5 0/5] RAID 0/1/10 atomic write support
  2024-11-19 17:05 ` John Garry
@ 2024-11-19 17:29   ` Jens Axboe
  2024-11-19 17:45     ` John Garry
  0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2024-11-19 17:29 UTC (permalink / raw)
  To: John Garry, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen

On 11/19/24 10:05 AM, John Garry wrote:
> On 18/11/2024 10:50, John Garry wrote:
>> This series introduces atomic write support for software RAID 0/1/10.
>>
>> The main changes are to ensure that we can calculate the stacked device
>> request_queue limits appropriately for atomic writes. Fundamentally, if
>> some bottom does not support atomic writes, then atomic writes are not
>> supported for the top device. Furthermore, the atomic writes limits are
>> the lowest common supported limits from all bottom devices.
>>
>> Flag BLK_FEAT_ATOMIC_WRITES_STACKED is introduced to enable atomic writes
>> for stacked devices selectively. This ensures that we can analyze and test
>> atomic writes support per individual md/dm personality (prior to
>> enabling).
>>
>> Based on 88d47f629313 (block/for-6.13/block) Merge tag
>> 'md-6.13-20241115' ofhttps://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux into for-6.13/block
> 
> Hi Jens,
> 
> In case you are planning on sending a 2nd batch of new dev for 6.13, I
> think that this is in mergeable state.
> 
> If not, I'll repost for 6.14 later.

I think we can do 6.13 for this one, I always do a later pull week after
merge window starts. And this has been posted previously as well, so
probably no reason to further delay it.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v5 0/5] RAID 0/1/10 atomic write support
  2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
                   ` (6 preceding siblings ...)
  2024-11-19 17:05 ` John Garry
@ 2024-11-19 17:30 ` Jens Axboe
  7 siblings, 0 replies; 11+ messages in thread
From: Jens Axboe @ 2024-11-19 17:30 UTC (permalink / raw)
  To: song, yukuai3, hch, John Garry
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen


On Mon, 18 Nov 2024 10:50:13 +0000, John Garry wrote:
> This series introduces atomic write support for software RAID 0/1/10.
> 
> The main changes are to ensure that we can calculate the stacked device
> request_queue limits appropriately for atomic writes. Fundamentally, if
> some bottom does not support atomic writes, then atomic writes are not
> supported for the top device. Furthermore, the atomic writes limits are
> the lowest common supported limits from all bottom devices.
> 
> [...]

Applied, thanks!

[1/5] block: Add extra checks in blk_validate_atomic_write_limits()
      commit: d00eea91deaf363f83599532cb49fa528ab8e00e
[2/5] block: Support atomic writes limits for stacked devices
      commit: d7f36dc446e894e0f57b5f05c5628f03c5f9e2d2
[3/5] md/raid0: Atomic write support
      commit: fa6fec82811bc6ebd3c4337ae4dae36c802c0fc1
[4/5] md/raid1: Atomic write support
      commit: f2a38abf5f1c5aeb3be8e9f4d3d815c867fff7ca
[5/5] md/raid10: Atomic write support
      commit: a1d9b4fd42d93f46c11e7e9d919a55a3f6ca6126

Best regards,
-- 
Jens Axboe




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v5 0/5] RAID 0/1/10 atomic write support
  2024-11-19 17:29   ` Jens Axboe
@ 2024-11-19 17:45     ` John Garry
  0 siblings, 0 replies; 11+ messages in thread
From: John Garry @ 2024-11-19 17:45 UTC (permalink / raw)
  To: Jens Axboe, song, yukuai3, hch
  Cc: linux-block, linux-kernel, linux-raid, martin.petersen

On 19/11/2024 17:29, Jens Axboe wrote:
>> If not, I'll repost for 6.14 later.
> I think we can do 6.13 for this one, I always do a later pull week after
> merge window starts. And this has been posted previously as well, so
> probably no reason to further delay it.

great, thanks

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2024-11-19 17:45 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-18 10:50 [PATCH v5 0/5] RAID 0/1/10 atomic write support John Garry
2024-11-18 10:50 ` [PATCH v5 1/5] block: Add extra checks in blk_validate_atomic_write_limits() John Garry
2024-11-18 10:50 ` [PATCH v5 2/5] block: Support atomic writes limits for stacked devices John Garry
2024-11-18 10:50 ` [PATCH v5 3/5] md/raid0: Atomic write support John Garry
2024-11-18 10:50 ` [PATCH v5 4/5] md/raid1: " John Garry
2024-11-18 10:50 ` [PATCH v5 5/5] md/raid10: " John Garry
2024-11-19  1:37 ` [PATCH v5 0/5] RAID 0/1/10 atomic " Martin K. Petersen
2024-11-19 17:05 ` John Garry
2024-11-19 17:29   ` Jens Axboe
2024-11-19 17:45     ` John Garry
2024-11-19 17:30 ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).