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

[Mike Fleetwood]

On Mon, 6 Oct 2025 at 19:26, Butenko, Anton <abutenko at akamai.com> wrote:
> 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
This second commit says:
  Note that the optimal I/O size may be set by the DMA
  engines or SCSI controllers and they have no knowledge about the disks
  attached to them, so the situation with optimal I/O not aligned to
  physical block size may happen.

> /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
Aligning partitions to your optimal_io_size of 16773120 (=4095*4096)
seems dubious.

> 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?
Creating a setup where you align a partition to something other than MiB
and get a warning for not using the recommended MiB alignment is not
evidence of an issue.

Optimal I/O size is not storage alignment.  Previously when tools
aligned partitions to the optimal I/O size it resulted in misaligned
partitions [1].  Let's not do that again.  All the tools now align to
MiBs, even thoses on other OSs.

Mike Fleetwood
(GParted Developer)


[1] Partitions Misaligned to 33553920 Bytes and Invalid Optimal
Transfer Size Warning
    [The list of tools which I previously identified as misaligning
    partitions when I looked into it back in 2019]
    https://web.archive.org/web/20201024195647/http://gparted-forum.surf4.info/viewtopic.php?id=17839