[parted-devel] Parted PED_DEFAULT_ALIGNMENT is no more effective for SCSI disks in recent kernel

[Butenko, Anton]

Hello team,

After the relatively recent kernel update:
https://github.com/torvalds/linux/commit/a23634644afc2f7c1bac98776440a1f3b161819e
and some fixe after that:
https://github.com/torvalds/linux/commit/9c0ba14828d64744ccd195c610594ba254a1a9ab

/sys/block/<dev_labeL>/queue/optimal_io_size contains now much bigger values for SCSI disks
(actaully equal to the maximum DMA buffer size as I get it).

For example, I have a setup:
# cat /sys/block/sdp/queue/optimal_io_size
16773120
# cat /sys/block/sdp/queue/minimum_io_size
4096

A that, actually leads us to the next questions:
1. PED_DEFAULT_ALIGNMENT (1MiB) used in linux_get_optimum_alignment function is not effective for SCSI disks, as SCSI hosts now seem to have bigger maximum DMA buffer sizes.
   Is this needed to be revisited in parted? Like, having bigger alignment blocks can lead to some tricky behavior (like obvious thing partitions creation by user in MiBs will often lead to unaligned partitions)
2. We faced suboptimal behavior in our environment (at least it looks so), that can be easily reproduced with scsi_debug driver:

# Load scsi_debug with desired geometry (logical=512, physical=4096=512*2^3)
sudo modprobe scsi_debug dev_size_mb=160 sector_size=512 physblk_exp=3

# Identify the created device (e.g., /dev/sdb)
lsscsi -g | grep scsi_debug
[3:0:0:0]    disk    Linux    scsi_debug       0190  /dev/sdb   /dev/sg2

# Verify geometry
cat /sys/block/sdb/queue/minimum_io_size
4096
cat /sys/block/sdb/queue/optimal_io_size
524288
blockdev --getsize64 /dev/sdb
167772160


sudo ./parted --script /dev/sdb unit KiB mklabel gpt mkpart primary 256 100% print
Warning: The resulting partition is not properly aligned for best performance: 512s % 2048s != 0s
Model: Linux scsi_debug (scsi)
Disk /dev/sdb: 163840kiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End        Size       File system  Name     Flags
1      256kiB  163823kiB  163568kiB               primary

echo $?
0

And then we tried to create enctypted partition with optimized block size:
sudo cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/sdb1


With this parted prints just warning and leaves partition unaligned:
Warning: The resulting partition is not properly aligned for best performance: 512s % 2048s != 0s
But, I think we can optimize the behavior aligning the first block to the optimal sector size (if optimal sector size is bigger).

And, instead of creating unaligned partition, provide user with the properly aligned one. This looks better to me as a "best effort" action.
What do you think?

Thank you,

Anton Butenko

P.S. I’m attaching patch variant, but that may be done in better way (like creating some new function that does that)

---
diff --git pkgsrc.orig/parted/parted.c pkgsrc/parted/parted.c
index fc2aeba..b317c2c 100644
--- pkgsrc.orig/parted/parted.c
+++ pkgsrc/parted/parted.c
@@ -750,6 +761,12 @@ do_mkpart (PedDevice** dev, PedDisk** diskp)
         else
                 dev_constraint = ped_device_get_constraint(*dev);
         PED_ASSERT (dev_constraint != NULL);
+        if (user_constraint->start_range->end < dev_constraint->start_align->grain_size) {
+                /* We should always start partition from the aligned point or
+                   parted will be not able to resolve the partition constraints.
+                */
+                user_constraint->start_range->end = dev_constraint->start_align->grain_size;
+        }
         final_constraint = ped_constraint_intersect (user_constraint,
                         dev_constraint);
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/parted-devel/attachments/20251003/074ae616/attachment-0001.htm>