* [PATCH v4 0/2] make logical_block_size configurable
@ 2025-09-11 7:31 linan666
2025-09-11 7:31 ` [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays linan666
2025-09-11 7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666
0 siblings, 2 replies; 11+ messages in thread
From: linan666 @ 2025-09-11 7:31 UTC (permalink / raw)
To: corbet, song, yukuai3, linan122, xni, hare
Cc: martin.petersen, bvanassche, filipe.c.maia, linux-doc,
linux-kernel, linux-raid, linan666, yangerkun, yi.zhang
From: Li Nan <linan122@huawei.com>
v4:
patch 1: add fix tag.
patch 2:
- add documentation for sysfs.
- only support metadata format 1.x.
- do not call md_update_sb when writing sysfs. mddev->pers is NULL here.
- return directly before hold lock in lbs_store.
v3:
- logical_block_size must not exceed PAGE_SIZE for bio device.
- Assign lim to mddev rather than to gendisk in mddev_stack_rdev_limits().
- Remove the patch that modifies the return value.
v2: No new exported interfaces are introduced.
Li Nan (2):
md: prevent adding disks with larger logical_block_size to active
arrays
md: allow configuring logical_block_size
Documentation/admin-guide/md.rst | 7 +++
drivers/md/md.h | 1 +
include/uapi/linux/raid/md_p.h | 3 +-
drivers/md/md-linear.c | 1 +
drivers/md/md.c | 82 ++++++++++++++++++++++++++++++++
drivers/md/raid0.c | 1 +
drivers/md/raid1.c | 1 +
drivers/md/raid10.c | 1 +
drivers/md/raid5.c | 1 +
9 files changed, 97 insertions(+), 1 deletion(-)
--
2.39.2
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays 2025-09-11 7:31 [PATCH v4 0/2] make logical_block_size configurable linan666 @ 2025-09-11 7:31 ` linan666 2025-09-12 3:18 ` Xiao Ni 2025-09-11 7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666 1 sibling, 1 reply; 11+ messages in thread From: linan666 @ 2025-09-11 7:31 UTC (permalink / raw) To: corbet, song, yukuai3, linan122, xni, hare Cc: martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, linan666, yangerkun, yi.zhang From: Li Nan <linan122@huawei.com> When adding a disk to a md array, avoid updating the array's logical_block_size to match the new disk. This prevents accidental partition table loss that renders the array unusable. The later patch will introduce a way to configure the array's logical_block_size. The issue was introduced before Linux 2.6.12-rc2. Fixes: d2e45eace8 ("[PATCH] Fix raid "bio too big" failures") Signed-off-by: Li Nan <linan122@huawei.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> --- drivers/md/md.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index a77c59527d4c..40f56183c744 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6064,6 +6064,13 @@ int mddev_stack_new_rdev(struct mddev *mddev, struct md_rdev *rdev) if (mddev_is_dm(mddev)) return 0; + if (queue_logical_block_size(rdev->bdev->bd_disk->queue) > + queue_logical_block_size(mddev->gendisk->queue)) { + pr_err("%s: incompatible logical_block_size, can not add\n", + mdname(mddev)); + return -EINVAL; + } + lim = queue_limits_start_update(mddev->gendisk->queue); queue_limits_stack_bdev(&lim, rdev->bdev, rdev->data_offset, mddev->gendisk->disk_name); -- 2.39.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays 2025-09-11 7:31 ` [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays linan666 @ 2025-09-12 3:18 ` Xiao Ni 2025-09-12 9:20 ` Li Nan 0 siblings, 1 reply; 11+ messages in thread From: Xiao Ni @ 2025-09-12 3:18 UTC (permalink / raw) To: linan666 Cc: corbet, song, yukuai3, linan122, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: > > From: Li Nan <linan122@huawei.com> > > When adding a disk to a md array, avoid updating the array's > logical_block_size to match the new disk. This prevents accidental > partition table loss that renders the array unusable. > > The later patch will introduce a way to configure the array's > logical_block_size. > > The issue was introduced before Linux 2.6.12-rc2. > > Fixes: d2e45eace8 ("[PATCH] Fix raid "bio too big" failures") Hi Li Nan I can't find the commit in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git show d2e45eace8 fatal: ambiguous argument 'd2e45eace8': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' Regards Xiao > Signed-off-by: Li Nan <linan122@huawei.com> > Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> > --- > drivers/md/md.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index a77c59527d4c..40f56183c744 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -6064,6 +6064,13 @@ int mddev_stack_new_rdev(struct mddev *mddev, struct md_rdev *rdev) > if (mddev_is_dm(mddev)) > return 0; > > + if (queue_logical_block_size(rdev->bdev->bd_disk->queue) > > + queue_logical_block_size(mddev->gendisk->queue)) { > + pr_err("%s: incompatible logical_block_size, can not add\n", > + mdname(mddev)); > + return -EINVAL; > + } > + > lim = queue_limits_start_update(mddev->gendisk->queue); > queue_limits_stack_bdev(&lim, rdev->bdev, rdev->data_offset, > mddev->gendisk->disk_name); > -- > 2.39.2 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays 2025-09-12 3:18 ` Xiao Ni @ 2025-09-12 9:20 ` Li Nan 0 siblings, 0 replies; 11+ messages in thread From: Li Nan @ 2025-09-12 9:20 UTC (permalink / raw) To: Xiao Ni, linan666 Cc: corbet, song, yukuai3, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang 在 2025/9/12 11:18, Xiao Ni 写道: > On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: >> >> From: Li Nan <linan122@huawei.com> >> >> When adding a disk to a md array, avoid updating the array's >> logical_block_size to match the new disk. This prevents accidental >> partition table loss that renders the array unusable. >> >> The later patch will introduce a way to configure the array's >> logical_block_size. >> >> The issue was introduced before Linux 2.6.12-rc2. >> >> Fixes: d2e45eace8 ("[PATCH] Fix raid "bio too big" failures") > > Hi Li Nan > > I can't find the commit in > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git show d2e45eace8 > fatal: ambiguous argument 'd2e45eace8': unknown revision or path not > in the working tree. > Use '--' to separate paths from revisions, like this: > 'git <command> [<revision>...] -- [<file>...]' > > Regards > Xiao Thank you for your reply. As mentioned in the commit message, the issue was introduced before Linux 2.6.12-rc2, and needs to be get it in the history repository. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tglx/history.git -- Thanks, Nan ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-11 7:31 [PATCH v4 0/2] make logical_block_size configurable linan666 2025-09-11 7:31 ` [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays linan666 @ 2025-09-11 7:31 ` linan666 2025-09-11 8:05 ` Paul Menzel 2025-09-15 0:33 ` Xiao Ni 1 sibling, 2 replies; 11+ messages in thread From: linan666 @ 2025-09-11 7:31 UTC (permalink / raw) To: corbet, song, yukuai3, linan122, xni, hare Cc: martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, linan666, yangerkun, yi.zhang From: Li Nan <linan122@huawei.com> Previously, raid array used the maximum logical_block_size (LBS) of all member disks. Adding a larger LBS during disk at runtime could unexpectedly increase RAID's LBS, risking corruption of existing partitions. Simply restricting larger-LBS disks is inflexible. In some scenarios, only disks with 512 LBS are available currently, but later, disks with 4k LBS may be added to the array. Making LBS configurable is the best way to solve this scenario. After this patch, the raid will: - stores LBS in disk metadata. - add a read-write sysfs 'mdX/logical_block_size'. Future mdadm should support setting LBS via metadata field during RAID creation and the new sysfs. Though the kernel allows runtime LBS changes, users should avoid modifying it after creating partitions or filesystems to prevent compatibility issues. Note that many RAID paths rely on PAGE_SIZE alignment, including for metadata I/O. A logical_block_size larger than PAGE_SIZE will result in metadata reads/writes failures. So this config should be prevented. Only 1.x meta supports configurable logical_block_size. 0.90 meta init all fields to default at auto-detect. Supporting 0.90 would require more extensive changes and no such use case has been observed. Signed-off-by: Li Nan <linan122@huawei.com> --- Documentation/admin-guide/md.rst | 7 +++ drivers/md/md.h | 1 + include/uapi/linux/raid/md_p.h | 3 +- drivers/md/md-linear.c | 1 + drivers/md/md.c | 75 ++++++++++++++++++++++++++++++++ drivers/md/raid0.c | 1 + drivers/md/raid1.c | 1 + drivers/md/raid10.c | 1 + drivers/md/raid5.c | 1 + 9 files changed, 90 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst index 1c2eacc94758..f5c81fad034a 100644 --- a/Documentation/admin-guide/md.rst +++ b/Documentation/admin-guide/md.rst @@ -238,6 +238,13 @@ All md devices contain: the number of devices in a raid4/5/6, or to support external metadata formats which mandate such clipping. + logical_block_size + Configures the array's logical block size in bytes. This attribute + is only supported for RAID1, RAID5, RAID10 with 1.x meta. The value + should be written before starting the array. The final array LBS + will use the max value between this configuration and all rdev's LBS. + Note that LBS cannot exceed PAGE_SIZE. + reshape_position This is either ``none`` or a sector number within the devices of the array where ``reshape`` is up to. If this is set, the three diff --git a/drivers/md/md.h b/drivers/md/md.h index afb25f727409..b0147b98c8d3 100644 --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -432,6 +432,7 @@ struct mddev { sector_t array_sectors; /* exported array size */ int external_size; /* size managed * externally */ + unsigned int logical_block_size; __u64 events; /* If the last 'event' was simply a clean->dirty transition, and * we didn't write it to the spares, then it is safe and simple diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h index ac74133a4768..310068bb2a1d 100644 --- a/include/uapi/linux/raid/md_p.h +++ b/include/uapi/linux/raid/md_p.h @@ -291,7 +291,8 @@ struct mdp_superblock_1 { __le64 resync_offset; /* data before this offset (from data_offset) known to be in sync */ __le32 sb_csum; /* checksum up to devs[max_dev] */ __le32 max_dev; /* size of devs[] array to consider */ - __u8 pad3[64-32]; /* set to 0 when writing */ + __le32 logical_block_size; /* same as q->limits->logical_block_size */ + __u8 pad3[64-36]; /* set to 0 when writing */ /* device state information. Indexed by dev_number. * 2 bytes per device diff --git a/drivers/md/md-linear.c b/drivers/md/md-linear.c index 5d9b08115375..da8babb8da59 100644 --- a/drivers/md/md-linear.c +++ b/drivers/md/md-linear.c @@ -72,6 +72,7 @@ static int linear_set_limits(struct mddev *mddev) md_init_stacking_limits(&lim); lim.max_hw_sectors = mddev->chunk_sectors; + lim.logical_block_size = mddev->logical_block_size; lim.max_write_zeroes_sectors = mddev->chunk_sectors; lim.io_min = mddev->chunk_sectors << 9; err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); diff --git a/drivers/md/md.c b/drivers/md/md.c index 40f56183c744..e0184942c8ec 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -1963,6 +1963,7 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *freshest, struc mddev->layout = le32_to_cpu(sb->layout); mddev->raid_disks = le32_to_cpu(sb->raid_disks); mddev->dev_sectors = le64_to_cpu(sb->size); + mddev->logical_block_size = le32_to_cpu(sb->logical_block_size); mddev->events = ev1; mddev->bitmap_info.offset = 0; mddev->bitmap_info.space = 0; @@ -2172,6 +2173,7 @@ static void super_1_sync(struct mddev *mddev, struct md_rdev *rdev) sb->chunksize = cpu_to_le32(mddev->chunk_sectors); sb->level = cpu_to_le32(mddev->level); sb->layout = cpu_to_le32(mddev->layout); + sb->logical_block_size = cpu_to_le32(mddev->logical_block_size); if (test_bit(FailFast, &rdev->flags)) sb->devflags |= FailFast1; else @@ -5900,6 +5902,66 @@ static struct md_sysfs_entry md_serialize_policy = __ATTR(serialize_policy, S_IRUGO | S_IWUSR, serialize_policy_show, serialize_policy_store); +static int mddev_set_logical_block_size(struct mddev *mddev, + unsigned int lbs) +{ + int err = 0; + struct queue_limits lim; + + if (queue_logical_block_size(mddev->gendisk->queue) >= lbs) { + pr_err("%s: incompatible logical_block_size %u, can not set\n", + mdname(mddev), lbs); + return -EINVAL; + } + + lim = queue_limits_start_update(mddev->gendisk->queue); + lim.logical_block_size = lbs; + pr_info("%s: logical_block_size is changed, data may be lost\n", + mdname(mddev)); + err = queue_limits_commit_update(mddev->gendisk->queue, &lim); + if (err) + return err; + + mddev->logical_block_size = lbs; + return 0; +} + +static ssize_t +lbs_show(struct mddev *mddev, char *page) +{ + return sprintf(page, "%u\n", mddev->logical_block_size); +} + +static ssize_t +lbs_store(struct mddev *mddev, const char *buf, size_t len) +{ + unsigned int lbs; + int err = -EBUSY; + + /* Only 1.x meta supports configurable LBS */ + if (mddev->major_version == 0) + return -EINVAL; + + if (mddev->pers) + return -EBUSY; + + err = kstrtouint(buf, 10, &lbs); + if (err < 0) + return -EINVAL; + + err = mddev_lock(mddev); + if (err) + goto unlock; + + err = mddev_set_logical_block_size(mddev, lbs); + +unlock: + mddev_unlock(mddev); + return err ?: len; +} + +static struct md_sysfs_entry md_logical_block_size = +__ATTR(logical_block_size, S_IRUGO|S_IWUSR, lbs_show, lbs_store); static struct attribute *md_default_attrs[] = { &md_level.attr, @@ -5933,6 +5995,7 @@ static struct attribute *md_redundancy_attrs[] = { &md_scan_mode.attr, &md_last_scan_mode.attr, &md_mismatches.attr, + &md_logical_block_size.attr, &md_sync_min.attr, &md_sync_max.attr, &md_sync_io_depth.attr, @@ -6052,6 +6115,17 @@ int mddev_stack_rdev_limits(struct mddev *mddev, struct queue_limits *lim, return -EINVAL; } + /* + * Before RAID adding folio support, the logical_block_size + * should be smaller than the page size. + */ + if (lim->logical_block_size > PAGE_SIZE) { + pr_err("%s: logical_block_size must not larger than PAGE_SIZE\n", + mdname(mddev)); + return -EINVAL; + } + mddev->logical_block_size = lim->logical_block_size; + return 0; } EXPORT_SYMBOL_GPL(mddev_stack_rdev_limits); @@ -6690,6 +6764,7 @@ static void md_clean(struct mddev *mddev) mddev->chunk_sectors = 0; mddev->ctime = mddev->utime = 0; mddev->layout = 0; + mddev->logical_block_size = 0; mddev->max_disks = 0; mddev->events = 0; mddev->can_decrease_events = 0; diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c index f1d8811a542a..705889a09fc1 100644 --- a/drivers/md/raid0.c +++ b/drivers/md/raid0.c @@ -382,6 +382,7 @@ static int raid0_set_limits(struct mddev *mddev) md_init_stacking_limits(&lim); lim.max_hw_sectors = mddev->chunk_sectors; lim.max_write_zeroes_sectors = mddev->chunk_sectors; + lim.logical_block_size = mddev->logical_block_size; lim.io_min = mddev->chunk_sectors << 9; lim.io_opt = lim.io_min * mddev->raid_disks; lim.chunk_sectors = mddev->chunk_sectors; diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index d0f6afd2f988..de0c843067dc 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c @@ -3223,6 +3223,7 @@ static int raid1_set_limits(struct mddev *mddev) md_init_stacking_limits(&lim); lim.max_write_zeroes_sectors = 0; + lim.logical_block_size = mddev->logical_block_size; lim.features |= BLK_FEAT_ATOMIC_WRITES; err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); if (err) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index c3cfbb0347e7..68c8148386b0 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -4005,6 +4005,7 @@ static int raid10_set_queue_limits(struct mddev *mddev) md_init_stacking_limits(&lim); lim.max_write_zeroes_sectors = 0; + lim.logical_block_size = mddev->logical_block_size; lim.io_min = mddev->chunk_sectors << 9; lim.chunk_sectors = mddev->chunk_sectors; lim.io_opt = lim.io_min * raid10_nr_stripes(conf); diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index c32ffd9cffce..ff0daa22df65 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -7747,6 +7747,7 @@ static int raid5_set_limits(struct mddev *mddev) stripe = roundup_pow_of_two(data_disks * (mddev->chunk_sectors << 9)); md_init_stacking_limits(&lim); + lim.logical_block_size = mddev->logical_block_size; lim.io_min = mddev->chunk_sectors << 9; lim.io_opt = lim.io_min * (conf->raid_disks - conf->max_degraded); lim.features |= BLK_FEAT_RAID_PARTIAL_STRIPES_EXPENSIVE; -- 2.39.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-11 7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666 @ 2025-09-11 8:05 ` Paul Menzel 2025-09-12 9:27 ` Li Nan 2025-09-15 0:33 ` Xiao Ni 1 sibling, 1 reply; 11+ messages in thread From: Paul Menzel @ 2025-09-11 8:05 UTC (permalink / raw) To: Li Nan Cc: corbet, song, yukuai3, linan122, xni, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang Dear Nan, Thank you for your patch. Some minor nits. i’d write logical block size without underscores in the summary and commit message body, if the variable is not referenced. Am 11.09.25 um 09:31 schrieb linan666@huaweicloud.com: > From: Li Nan <linan122@huawei.com> > > Previously, raid array used the maximum logical_block_size (LBS) of > all member disks. Adding a larger LBS during disk at runtime could … when adding a disk …? > unexpectedly increase RAID's LBS, risking corruption of existing > partitions. > > Simply restricting larger-LBS disks is inflexible. In some scenarios, > only disks with 512 LBS are available currently, but later, disks with 512 bytes > 4k LBS may be added to the array. 4 kB > Making LBS configurable is the best way to solve this scenario. > After this patch, the raid will: > - stores LBS in disk metadata. store without 3rd person s > - add a read-write sysfs 'mdX/logical_block_size'. I’d remove the the dot/period at the end of the items. > Future mdadm should support setting LBS via metadata field during RAID > creation and the new sysfs. Though the kernel allows runtime LBS changes, > users should avoid modifying it after creating partitions or filesystems > to prevent compatibility issues. > > Note that many RAID paths rely on PAGE_SIZE alignment, including for > metadata I/O. A logical_block_size larger than PAGE_SIZE will result in > metadata reads/writes failures. So this config should be prevented. read/write > Only 1.x meta supports configurable logical_block_size. 0.90 meta init initializes/init*s* > all fields to default at auto-detect. Supporting 0.90 would require more > extensive changes and no such use case has been observed. It’d be great if you added a section, how you tested your patch. > Signed-off-by: Li Nan <linan122@huawei.com> > --- > Documentation/admin-guide/md.rst | 7 +++ > drivers/md/md.h | 1 + > include/uapi/linux/raid/md_p.h | 3 +- > drivers/md/md-linear.c | 1 + > drivers/md/md.c | 75 ++++++++++++++++++++++++++++++++ > drivers/md/raid0.c | 1 + > drivers/md/raid1.c | 1 + > drivers/md/raid10.c | 1 + > drivers/md/raid5.c | 1 + > 9 files changed, 90 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst > index 1c2eacc94758..f5c81fad034a 100644 > --- a/Documentation/admin-guide/md.rst > +++ b/Documentation/admin-guide/md.rst > @@ -238,6 +238,13 @@ All md devices contain: > the number of devices in a raid4/5/6, or to support external > metadata formats which mandate such clipping. > > + logical_block_size > + Configures the array's logical block size in bytes. This attribute > + is only supported for RAID1, RAID5, RAID10 with 1.x meta. The value metadata > + should be written before starting the array. The final array LBS > + will use the max value between this configuration and all rdev's LBS. Should rdev be explained in the documentation? > + Note that LBS cannot exceed PAGE_SIZE. How can PAGE_SIZE be determined? To be clear, that the implementation disallows this: Not, LBS values larger than PAGE_SIZE are rejected. > + > reshape_position > This is either ``none`` or a sector number within the devices of > the array where ``reshape`` is up to. If this is set, the three > diff --git a/drivers/md/md.h b/drivers/md/md.h > index afb25f727409..b0147b98c8d3 100644 > --- a/drivers/md/md.h > +++ b/drivers/md/md.h > @@ -432,6 +432,7 @@ struct mddev { > sector_t array_sectors; /* exported array size */ > int external_size; /* size managed > * externally */ > + unsigned int logical_block_size; > __u64 events; > /* If the last 'event' was simply a clean->dirty transition, and > * we didn't write it to the spares, then it is safe and simple > diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h > index ac74133a4768..310068bb2a1d 100644 > --- a/include/uapi/linux/raid/md_p.h > +++ b/include/uapi/linux/raid/md_p.h > @@ -291,7 +291,8 @@ struct mdp_superblock_1 { > __le64 resync_offset; /* data before this offset (from data_offset) known to be in sync */ > __le32 sb_csum; /* checksum up to devs[max_dev] */ > __le32 max_dev; /* size of devs[] array to consider */ > - __u8 pad3[64-32]; /* set to 0 when writing */ > + __le32 logical_block_size; /* same as q->limits->logical_block_size */ > + __u8 pad3[64-36]; /* set to 0 when writing */ > > /* device state information. Indexed by dev_number. > * 2 bytes per device > diff --git a/drivers/md/md-linear.c b/drivers/md/md-linear.c > index 5d9b08115375..da8babb8da59 100644 > --- a/drivers/md/md-linear.c > +++ b/drivers/md/md-linear.c > @@ -72,6 +72,7 @@ static int linear_set_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_hw_sectors = mddev->chunk_sectors; > + lim.logical_block_size = mddev->logical_block_size; > lim.max_write_zeroes_sectors = mddev->chunk_sectors; > lim.io_min = mddev->chunk_sectors << 9; > err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 40f56183c744..e0184942c8ec 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -1963,6 +1963,7 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *freshest, struc > mddev->layout = le32_to_cpu(sb->layout); > mddev->raid_disks = le32_to_cpu(sb->raid_disks); > mddev->dev_sectors = le64_to_cpu(sb->size); > + mddev->logical_block_size = le32_to_cpu(sb->logical_block_size); > mddev->events = ev1; > mddev->bitmap_info.offset = 0; > mddev->bitmap_info.space = 0; > @@ -2172,6 +2173,7 @@ static void super_1_sync(struct mddev *mddev, struct md_rdev *rdev) > sb->chunksize = cpu_to_le32(mddev->chunk_sectors); > sb->level = cpu_to_le32(mddev->level); > sb->layout = cpu_to_le32(mddev->layout); > + sb->logical_block_size = cpu_to_le32(mddev->logical_block_size); > if (test_bit(FailFast, &rdev->flags)) > sb->devflags |= FailFast1; > else > @@ -5900,6 +5902,66 @@ static struct md_sysfs_entry md_serialize_policy = > __ATTR(serialize_policy, S_IRUGO | S_IWUSR, serialize_policy_show, > serialize_policy_store); > > +static int mddev_set_logical_block_size(struct mddev *mddev, > + unsigned int lbs) > +{ > + int err = 0; > + struct queue_limits lim; > + > + if (queue_logical_block_size(mddev->gendisk->queue) >= lbs) { > + pr_err("%s: incompatible logical_block_size %u, can not set\n", Please also log `queue_logical_block_size(mddev->gendisk->queue)`. > + mdname(mddev), lbs); > + return -EINVAL; > + } > + > + lim = queue_limits_start_update(mddev->gendisk->queue); > + lim.logical_block_size = lbs; > + pr_info("%s: logical_block_size is changed, data may be lost\n", > + mdname(mddev)); Please print the values, and maybe make it a warning as data loss is possible? > + err = queue_limits_commit_update(mddev->gendisk->queue, &lim); > + if (err) > + return err; > + > + mddev->logical_block_size = lbs; > + return 0; > +} > + > +static ssize_t > +lbs_show(struct mddev *mddev, char *page) > +{ > + return sprintf(page, "%u\n", mddev->logical_block_size); > +} > + > +static ssize_t > +lbs_store(struct mddev *mddev, const char *buf, size_t len) > +{ > + unsigned int lbs; > + int err = -EBUSY; > + > + /* Only 1.x meta supports configurable LBS */ metadata > + if (mddev->major_version == 0) > + return -EINVAL; > + > + if (mddev->pers) > + return -EBUSY; > + > + err = kstrtouint(buf, 10, &lbs); > + if (err < 0) > + return -EINVAL; > + > + err = mddev_lock(mddev); > + if (err) > + goto unlock; > + > + err = mddev_set_logical_block_size(mddev, lbs); > + > +unlock: > + mddev_unlock(mddev); > + return err ?: len; No idea, if a space should be added before the colon :. > +} > + > +static struct md_sysfs_entry md_logical_block_size = > +__ATTR(logical_block_size, S_IRUGO|S_IWUSR, lbs_show, lbs_store); > > static struct attribute *md_default_attrs[] = { > &md_level.attr, > @@ -5933,6 +5995,7 @@ static struct attribute *md_redundancy_attrs[] = { > &md_scan_mode.attr, > &md_last_scan_mode.attr, > &md_mismatches.attr, > + &md_logical_block_size.attr, > &md_sync_min.attr, > &md_sync_max.attr, > &md_sync_io_depth.attr, > @@ -6052,6 +6115,17 @@ int mddev_stack_rdev_limits(struct mddev *mddev, struct queue_limits *lim, > return -EINVAL; > } > > + /* > + * Before RAID adding folio support, the logical_block_size > + * should be smaller than the page size. > + */ > + if (lim->logical_block_size > PAGE_SIZE) { > + pr_err("%s: logical_block_size must not larger than PAGE_SIZE\n", 1. not *be* larger 2. Please print the value of PAGE_SIZE. > + mdname(mddev)); > + return -EINVAL; > + } > + mddev->logical_block_size = lim->logical_block_size; > + > return 0; > } > EXPORT_SYMBOL_GPL(mddev_stack_rdev_limits); > @@ -6690,6 +6764,7 @@ static void md_clean(struct mddev *mddev) > mddev->chunk_sectors = 0; > mddev->ctime = mddev->utime = 0; > mddev->layout = 0; > + mddev->logical_block_size = 0; > mddev->max_disks = 0; > mddev->events = 0; > mddev->can_decrease_events = 0; > diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c > index f1d8811a542a..705889a09fc1 100644 > --- a/drivers/md/raid0.c > +++ b/drivers/md/raid0.c > @@ -382,6 +382,7 @@ static int raid0_set_limits(struct mddev *mddev) > md_init_stacking_limits(&lim); > lim.max_hw_sectors = mddev->chunk_sectors; > lim.max_write_zeroes_sectors = mddev->chunk_sectors; > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.io_opt = lim.io_min * mddev->raid_disks; > lim.chunk_sectors = mddev->chunk_sectors; > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c > index d0f6afd2f988..de0c843067dc 100644 > --- a/drivers/md/raid1.c > +++ b/drivers/md/raid1.c > @@ -3223,6 +3223,7 @@ static int raid1_set_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_write_zeroes_sectors = 0; > + lim.logical_block_size = mddev->logical_block_size; > lim.features |= BLK_FEAT_ATOMIC_WRITES; > err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); > if (err) > diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c > index c3cfbb0347e7..68c8148386b0 100644 > --- a/drivers/md/raid10.c > +++ b/drivers/md/raid10.c > @@ -4005,6 +4005,7 @@ static int raid10_set_queue_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_write_zeroes_sectors = 0; > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.chunk_sectors = mddev->chunk_sectors; > lim.io_opt = lim.io_min * raid10_nr_stripes(conf); > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index c32ffd9cffce..ff0daa22df65 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -7747,6 +7747,7 @@ static int raid5_set_limits(struct mddev *mddev) > stripe = roundup_pow_of_two(data_disks * (mddev->chunk_sectors << 9)); > > md_init_stacking_limits(&lim); > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.io_opt = lim.io_min * (conf->raid_disks - conf->max_degraded); > lim.features |= BLK_FEAT_RAID_PARTIAL_STRIPES_EXPENSIVE; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-11 8:05 ` Paul Menzel @ 2025-09-12 9:27 ` Li Nan 0 siblings, 0 replies; 11+ messages in thread From: Li Nan @ 2025-09-12 9:27 UTC (permalink / raw) To: Paul Menzel, Li Nan Cc: corbet, song, yukuai3, xni, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang 在 2025/9/11 16:05, Paul Menzel 写道: > Dear Nan, > > > Thank you for your patch. Some minor nits. i’d write logical block size > without underscores in the summary and commit message body, if the variable > is not referenced. > [...] Hi Paul, Thaks for your review. I'll address the points you mentioned in the next patch version. -- Thanks, Nan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-11 7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666 2025-09-11 8:05 ` Paul Menzel @ 2025-09-15 0:33 ` Xiao Ni 2025-09-15 2:15 ` Li Nan 1 sibling, 1 reply; 11+ messages in thread From: Xiao Ni @ 2025-09-15 0:33 UTC (permalink / raw) To: linan666 Cc: corbet, song, yukuai3, linan122, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang Hi Nan On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: > > From: Li Nan <linan122@huawei.com> > > Previously, raid array used the maximum logical_block_size (LBS) of > all member disks. Adding a larger LBS during disk at runtime could > unexpectedly increase RAID's LBS, risking corruption of existing > partitions. Could you describe more about the problem? It's better to give some test steps that can be used to reproduce this problem. > > Simply restricting larger-LBS disks is inflexible. In some scenarios, > only disks with 512 LBS are available currently, but later, disks with > 4k LBS may be added to the array. > > Making LBS configurable is the best way to solve this scenario. > After this patch, the raid will: > - stores LBS in disk metadata. > - add a read-write sysfs 'mdX/logical_block_size'. > > Future mdadm should support setting LBS via metadata field during RAID > creation and the new sysfs. Though the kernel allows runtime LBS changes, > users should avoid modifying it after creating partitions or filesystems > to prevent compatibility issues. Because it only allows setting when creating an array. Can this be done automatically in kernel space? Best Regards Xiao > > Note that many RAID paths rely on PAGE_SIZE alignment, including for > metadata I/O. A logical_block_size larger than PAGE_SIZE will result in > metadata reads/writes failures. So this config should be prevented. > > Only 1.x meta supports configurable logical_block_size. 0.90 meta init > all fields to default at auto-detect. Supporting 0.90 would require more > extensive changes and no such use case has been observed. > > Signed-off-by: Li Nan <linan122@huawei.com> > --- > Documentation/admin-guide/md.rst | 7 +++ > drivers/md/md.h | 1 + > include/uapi/linux/raid/md_p.h | 3 +- > drivers/md/md-linear.c | 1 + > drivers/md/md.c | 75 ++++++++++++++++++++++++++++++++ > drivers/md/raid0.c | 1 + > drivers/md/raid1.c | 1 + > drivers/md/raid10.c | 1 + > drivers/md/raid5.c | 1 + > 9 files changed, 90 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst > index 1c2eacc94758..f5c81fad034a 100644 > --- a/Documentation/admin-guide/md.rst > +++ b/Documentation/admin-guide/md.rst > @@ -238,6 +238,13 @@ All md devices contain: > the number of devices in a raid4/5/6, or to support external > metadata formats which mandate such clipping. > > + logical_block_size > + Configures the array's logical block size in bytes. This attribute > + is only supported for RAID1, RAID5, RAID10 with 1.x meta. The value > + should be written before starting the array. The final array LBS > + will use the max value between this configuration and all rdev's LBS. > + Note that LBS cannot exceed PAGE_SIZE. > + > reshape_position > This is either ``none`` or a sector number within the devices of > the array where ``reshape`` is up to. If this is set, the three > diff --git a/drivers/md/md.h b/drivers/md/md.h > index afb25f727409..b0147b98c8d3 100644 > --- a/drivers/md/md.h > +++ b/drivers/md/md.h > @@ -432,6 +432,7 @@ struct mddev { > sector_t array_sectors; /* exported array size */ > int external_size; /* size managed > * externally */ > + unsigned int logical_block_size; > __u64 events; > /* If the last 'event' was simply a clean->dirty transition, and > * we didn't write it to the spares, then it is safe and simple > diff --git a/include/uapi/linux/raid/md_p.h b/include/uapi/linux/raid/md_p.h > index ac74133a4768..310068bb2a1d 100644 > --- a/include/uapi/linux/raid/md_p.h > +++ b/include/uapi/linux/raid/md_p.h > @@ -291,7 +291,8 @@ struct mdp_superblock_1 { > __le64 resync_offset; /* data before this offset (from data_offset) known to be in sync */ > __le32 sb_csum; /* checksum up to devs[max_dev] */ > __le32 max_dev; /* size of devs[] array to consider */ > - __u8 pad3[64-32]; /* set to 0 when writing */ > + __le32 logical_block_size; /* same as q->limits->logical_block_size */ > + __u8 pad3[64-36]; /* set to 0 when writing */ > > /* device state information. Indexed by dev_number. > * 2 bytes per device > diff --git a/drivers/md/md-linear.c b/drivers/md/md-linear.c > index 5d9b08115375..da8babb8da59 100644 > --- a/drivers/md/md-linear.c > +++ b/drivers/md/md-linear.c > @@ -72,6 +72,7 @@ static int linear_set_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_hw_sectors = mddev->chunk_sectors; > + lim.logical_block_size = mddev->logical_block_size; > lim.max_write_zeroes_sectors = mddev->chunk_sectors; > lim.io_min = mddev->chunk_sectors << 9; > err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 40f56183c744..e0184942c8ec 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -1963,6 +1963,7 @@ static int super_1_validate(struct mddev *mddev, struct md_rdev *freshest, struc > mddev->layout = le32_to_cpu(sb->layout); > mddev->raid_disks = le32_to_cpu(sb->raid_disks); > mddev->dev_sectors = le64_to_cpu(sb->size); > + mddev->logical_block_size = le32_to_cpu(sb->logical_block_size); > mddev->events = ev1; > mddev->bitmap_info.offset = 0; > mddev->bitmap_info.space = 0; > @@ -2172,6 +2173,7 @@ static void super_1_sync(struct mddev *mddev, struct md_rdev *rdev) > sb->chunksize = cpu_to_le32(mddev->chunk_sectors); > sb->level = cpu_to_le32(mddev->level); > sb->layout = cpu_to_le32(mddev->layout); > + sb->logical_block_size = cpu_to_le32(mddev->logical_block_size); > if (test_bit(FailFast, &rdev->flags)) > sb->devflags |= FailFast1; > else > @@ -5900,6 +5902,66 @@ static struct md_sysfs_entry md_serialize_policy = > __ATTR(serialize_policy, S_IRUGO | S_IWUSR, serialize_policy_show, > serialize_policy_store); > > +static int mddev_set_logical_block_size(struct mddev *mddev, > + unsigned int lbs) > +{ > + int err = 0; > + struct queue_limits lim; > + > + if (queue_logical_block_size(mddev->gendisk->queue) >= lbs) { > + pr_err("%s: incompatible logical_block_size %u, can not set\n", > + mdname(mddev), lbs); > + return -EINVAL; > + } > + > + lim = queue_limits_start_update(mddev->gendisk->queue); > + lim.logical_block_size = lbs; > + pr_info("%s: logical_block_size is changed, data may be lost\n", > + mdname(mddev)); > + err = queue_limits_commit_update(mddev->gendisk->queue, &lim); > + if (err) > + return err; > + > + mddev->logical_block_size = lbs; > + return 0; > +} > + > +static ssize_t > +lbs_show(struct mddev *mddev, char *page) > +{ > + return sprintf(page, "%u\n", mddev->logical_block_size); > +} > + > +static ssize_t > +lbs_store(struct mddev *mddev, const char *buf, size_t len) > +{ > + unsigned int lbs; > + int err = -EBUSY; > + > + /* Only 1.x meta supports configurable LBS */ > + if (mddev->major_version == 0) > + return -EINVAL; > + > + if (mddev->pers) > + return -EBUSY; > + > + err = kstrtouint(buf, 10, &lbs); > + if (err < 0) > + return -EINVAL; > + > + err = mddev_lock(mddev); > + if (err) > + goto unlock; > + > + err = mddev_set_logical_block_size(mddev, lbs); > + > +unlock: > + mddev_unlock(mddev); > + return err ?: len; > +} > + > +static struct md_sysfs_entry md_logical_block_size = > +__ATTR(logical_block_size, S_IRUGO|S_IWUSR, lbs_show, lbs_store); > > static struct attribute *md_default_attrs[] = { > &md_level.attr, > @@ -5933,6 +5995,7 @@ static struct attribute *md_redundancy_attrs[] = { > &md_scan_mode.attr, > &md_last_scan_mode.attr, > &md_mismatches.attr, > + &md_logical_block_size.attr, > &md_sync_min.attr, > &md_sync_max.attr, > &md_sync_io_depth.attr, > @@ -6052,6 +6115,17 @@ int mddev_stack_rdev_limits(struct mddev *mddev, struct queue_limits *lim, > return -EINVAL; > } > > + /* > + * Before RAID adding folio support, the logical_block_size > + * should be smaller than the page size. > + */ > + if (lim->logical_block_size > PAGE_SIZE) { > + pr_err("%s: logical_block_size must not larger than PAGE_SIZE\n", > + mdname(mddev)); > + return -EINVAL; > + } > + mddev->logical_block_size = lim->logical_block_size; > + > return 0; > } > EXPORT_SYMBOL_GPL(mddev_stack_rdev_limits); > @@ -6690,6 +6764,7 @@ static void md_clean(struct mddev *mddev) > mddev->chunk_sectors = 0; > mddev->ctime = mddev->utime = 0; > mddev->layout = 0; > + mddev->logical_block_size = 0; > mddev->max_disks = 0; > mddev->events = 0; > mddev->can_decrease_events = 0; > diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c > index f1d8811a542a..705889a09fc1 100644 > --- a/drivers/md/raid0.c > +++ b/drivers/md/raid0.c > @@ -382,6 +382,7 @@ static int raid0_set_limits(struct mddev *mddev) > md_init_stacking_limits(&lim); > lim.max_hw_sectors = mddev->chunk_sectors; > lim.max_write_zeroes_sectors = mddev->chunk_sectors; > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.io_opt = lim.io_min * mddev->raid_disks; > lim.chunk_sectors = mddev->chunk_sectors; > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c > index d0f6afd2f988..de0c843067dc 100644 > --- a/drivers/md/raid1.c > +++ b/drivers/md/raid1.c > @@ -3223,6 +3223,7 @@ static int raid1_set_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_write_zeroes_sectors = 0; > + lim.logical_block_size = mddev->logical_block_size; > lim.features |= BLK_FEAT_ATOMIC_WRITES; > err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY); > if (err) > diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c > index c3cfbb0347e7..68c8148386b0 100644 > --- a/drivers/md/raid10.c > +++ b/drivers/md/raid10.c > @@ -4005,6 +4005,7 @@ static int raid10_set_queue_limits(struct mddev *mddev) > > md_init_stacking_limits(&lim); > lim.max_write_zeroes_sectors = 0; > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.chunk_sectors = mddev->chunk_sectors; > lim.io_opt = lim.io_min * raid10_nr_stripes(conf); > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index c32ffd9cffce..ff0daa22df65 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -7747,6 +7747,7 @@ static int raid5_set_limits(struct mddev *mddev) > stripe = roundup_pow_of_two(data_disks * (mddev->chunk_sectors << 9)); > > md_init_stacking_limits(&lim); > + lim.logical_block_size = mddev->logical_block_size; > lim.io_min = mddev->chunk_sectors << 9; > lim.io_opt = lim.io_min * (conf->raid_disks - conf->max_degraded); > lim.features |= BLK_FEAT_RAID_PARTIAL_STRIPES_EXPENSIVE; > -- > 2.39.2 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-15 0:33 ` Xiao Ni @ 2025-09-15 2:15 ` Li Nan 2025-09-15 8:50 ` Xiao Ni 0 siblings, 1 reply; 11+ messages in thread From: Li Nan @ 2025-09-15 2:15 UTC (permalink / raw) To: Xiao Ni, linan666 Cc: corbet, song, yukuai3, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang 在 2025/9/15 8:33, Xiao Ni 写道: > Hi Nan > > On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: >> >> From: Li Nan <linan122@huawei.com> >> >> Previously, raid array used the maximum logical_block_size (LBS) of >> all member disks. Adding a larger LBS during disk at runtime could >> unexpectedly increase RAID's LBS, risking corruption of existing >> partitions. > > Could you describe more about the problem? It's better to give some > test steps that can be used to reproduce this problem. Thanks for your review. I will add reproducer in the next version. >> >> Simply restricting larger-LBS disks is inflexible. In some scenarios, >> only disks with 512 LBS are available currently, but later, disks with >> 4k LBS may be added to the array. >> >> Making LBS configurable is the best way to solve this scenario. >> After this patch, the raid will: >> - stores LBS in disk metadata. >> - add a read-write sysfs 'mdX/logical_block_size'. >> >> Future mdadm should support setting LBS via metadata field during RAID >> creation and the new sysfs. Though the kernel allows runtime LBS changes, >> users should avoid modifying it after creating partitions or filesystems >> to prevent compatibility issues. > > Because it only allows setting when creating an array. Can this be > done automatically in kernel space? > > Best Regards > Xiao The kernel defaults LBS to the max among all rdevs. When creating RAID with mdadm, if mdadm doesn't set LBS explicitly, how does the kernel learn the intended value? Gunaghao previously submitted a patch related to mdadm: https://lore.kernel.org/all/3a9fa346-1041-400d-b954-2119c1ea001c@huawei.com/ -- Thanks, Nan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-15 2:15 ` Li Nan @ 2025-09-15 8:50 ` Xiao Ni 2025-09-16 6:33 ` Li Nan 0 siblings, 1 reply; 11+ messages in thread From: Xiao Ni @ 2025-09-15 8:50 UTC (permalink / raw) To: Li Nan Cc: corbet, song, yukuai3, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang On Mon, Sep 15, 2025 at 10:15 AM Li Nan <linan666@huaweicloud.com> wrote: > > > > 在 2025/9/15 8:33, Xiao Ni 写道: > > Hi Nan > > > > On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: > >> > >> From: Li Nan <linan122@huawei.com> > >> > >> Previously, raid array used the maximum logical_block_size (LBS) of > >> all member disks. Adding a larger LBS during disk at runtime could > >> unexpectedly increase RAID's LBS, risking corruption of existing > >> partitions. > > > > Could you describe more about the problem? It's better to give some > > test steps that can be used to reproduce this problem. > > Thanks for your review. I will add reproducer in the next version. Thanks. > > >> > >> Simply restricting larger-LBS disks is inflexible. In some scenarios, > >> only disks with 512 LBS are available currently, but later, disks with > >> 4k LBS may be added to the array. > >> > >> Making LBS configurable is the best way to solve this scenario. > >> After this patch, the raid will: > >> - stores LBS in disk metadata. > >> - add a read-write sysfs 'mdX/logical_block_size'. > >> > >> Future mdadm should support setting LBS via metadata field during RAID > >> creation and the new sysfs. Though the kernel allows runtime LBS changes, > >> users should avoid modifying it after creating partitions or filesystems > >> to prevent compatibility issues. > > > > Because it only allows setting when creating an array. Can this be > > done automatically in kernel space? > > > > Best Regards > > Xiao > > The kernel defaults LBS to the max among all rdevs. When creating RAID > with mdadm, if mdadm doesn't set LBS explicitly, how does the kernel > learn the intended value? > > Gunaghao previously submitted a patch related to mdadm: > https://lore.kernel.org/all/3a9fa346-1041-400d-b954-2119c1ea001c@huawei.com/ Thanks for reminding me about this patch. First I still need to understand the problem. It may be a difficult thing for a user to choose the logcial block size. They don't know why they need to consider this value, right? If we only need a default value, the kernel space should be the right place? Regards Xiao > > -- > Thanks, > Nan > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] md: allow configuring logical_block_size 2025-09-15 8:50 ` Xiao Ni @ 2025-09-16 6:33 ` Li Nan 0 siblings, 0 replies; 11+ messages in thread From: Li Nan @ 2025-09-16 6:33 UTC (permalink / raw) To: Xiao Ni, Li Nan Cc: corbet, song, yukuai3, hare, martin.petersen, bvanassche, filipe.c.maia, linux-doc, linux-kernel, linux-raid, yangerkun, yi.zhang 在 2025/9/15 16:50, Xiao Ni 写道: > On Mon, Sep 15, 2025 at 10:15 AM Li Nan <linan666@huaweicloud.com> wrote: >> >> >> >> 在 2025/9/15 8:33, Xiao Ni 写道: >>> Hi Nan >>> >>> On Thu, Sep 11, 2025 at 3:41 PM <linan666@huaweicloud.com> wrote: >>>> >>>> From: Li Nan <linan122@huawei.com> >>>> >>>> Previously, raid array used the maximum logical_block_size (LBS) of >>>> all member disks. Adding a larger LBS during disk at runtime could >>>> unexpectedly increase RAID's LBS, risking corruption of existing >>>> partitions. >>> >>> Could you describe more about the problem? It's better to give some >>> test steps that can be used to reproduce this problem. >> >> Thanks for your review. I will add reproducer in the next version. > > Thanks. >> >>>> >>>> Simply restricting larger-LBS disks is inflexible. In some scenarios, >>>> only disks with 512 LBS are available currently, but later, disks with >>>> 4k LBS may be added to the array. >>>> >>>> Making LBS configurable is the best way to solve this scenario. >>>> After this patch, the raid will: >>>> - stores LBS in disk metadata. >>>> - add a read-write sysfs 'mdX/logical_block_size'. >>>> >>>> Future mdadm should support setting LBS via metadata field during RAID >>>> creation and the new sysfs. Though the kernel allows runtime LBS changes, >>>> users should avoid modifying it after creating partitions or filesystems >>>> to prevent compatibility issues. >>> >>> Because it only allows setting when creating an array. Can this be >>> done automatically in kernel space? >>> >>> Best Regards >>> Xiao >> >> The kernel defaults LBS to the max among all rdevs. When creating RAID >> with mdadm, if mdadm doesn't set LBS explicitly, how does the kernel >> learn the intended value? >> >> Gunaghao previously submitted a patch related to mdadm: >> https://lore.kernel.org/all/3a9fa346-1041-400d-b954-2119c1ea001c@huawei.com/ > > Thanks for reminding me about this patch. First I still need to > understand the problem. It may be a difficult thing for a user to Thank you for your response. Reproducer: https://lore.kernel.org/all/3e26e8a3-e0c1-cd40-af79-06424fb2d54b@huaweicloud.com/ I will add it to messge log in the next version. > choose the logcial block size. They don't know why they need to > consider this value, right? If we only need a default value, the > kernel space should be the right place? > The scenario of our product is that they have a mix of 4k LBS and 512 LBS disks. For most users, they do not need to modify the default values. This is difficult to solve through default values. > Regards > Xiao >> >> -- >> Thanks, >> Nan >> > > > . -- Thanks, Nan ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-09-16 6:33 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-09-11 7:31 [PATCH v4 0/2] make logical_block_size configurable linan666 2025-09-11 7:31 ` [PATCH v4 1/2] md: prevent adding disks with larger logical_block_size to active arrays linan666 2025-09-12 3:18 ` Xiao Ni 2025-09-12 9:20 ` Li Nan 2025-09-11 7:31 ` [PATCH v4 2/2] md: allow configuring logical_block_size linan666 2025-09-11 8:05 ` Paul Menzel 2025-09-12 9:27 ` Li Nan 2025-09-15 0:33 ` Xiao Ni 2025-09-15 2:15 ` Li Nan 2025-09-15 8:50 ` Xiao Ni 2025-09-16 6:33 ` Li Nan
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).