On Mon, 6 Oct 2025 at 19:26, Butenko, Anton <[email protected]> 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
