Topic: Users finding partitions are misaligned to 33553920 bytes
Partitions Misaligned to 33553920 Bytes and Invalid Optimal Transfer Size Warning
We have seen multiple reports of users with partitions that have been created misaligned to 33553920 bytes (32 MiB - 512 bytes). GParted has never created partitions misaligned like this, but several other tools have inadvertently done so.
Tools which are or have been affected include:
* fdisk  (Fixed in util-linux 2.27 )
* GNOME Disks 
* GNU Parted   
* OpenSUSE's YaST Partitioner 
* lmv2 pvcreate  
* cryptsetup  (Fixed in cryptsetup 2.0.0 )
This happens when:
1. HDDs (Hard Disk Drives) and SSDs (Solid State Drives) are plugged in via a USB-to-SATA adapter.
2. That controller reports an invalid optimal transfer size of 0xFFFF 512 byte sectors, (0xFFFF = 65535 decimal. 65535 * 512 = 33553920 bytes). 
3. Partition tool aligns new partitions to this invalid optimal transfer size.
Misaligned partition data leads to slower disk performance, some where between negligible to significant. It appears that the performance impact when using SSDs is minor, but the performance impact on HDDs can be more significant   . Note that this invalid optimal transfer size reported by a drive does not cause any performance issues by itself, only when data is accessed from misaligned partitions do performance issues occur. Therefore as long as partitions are aligned to MiB boundaries there will be no performance loss even if a controller reports an invalid optimal transfer size.
How to Discover if Partitions are Misaligned
Use fdisk -l to identify misaligned partitions. Misaligned partitions are those with a starting sector which is a multiple of 65535 512-byte sectors.
# fdisk -l Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors Disk model: SD600 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x6233fe45 Device Boot Start End Sectors Size Id Type /dev/sda1 * 65535 2228189 2162655 1G 83 Linux /dev/sda2 2228190 81132329 78904140 37.6G 83 Linux Partition 1 does not start on physical sector boundary. Partition 2 does not start on physical sector boundary.
Options if Misaligned Partitions are Discovered
After determining that your partitions are misaligned there are several options:
1. Do nothing if you don't notice the impact.
2. Backup your data, recreate all the partitions aligned to MiBs and restore your data.
3. Backup your data and move the partitions to be MiB aligned.
Identifiy Drives with Invalid Optimal Transfer Sizes
Optionally use lsblk -t to identify if any drives report an invalid optimal transfer size. The drives with optimal transfer size (OPT-IO) of 33553920 bytes are invalid.
$ lsblk -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 32M ├─sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 32M └─sda2 0 4096 33553920 4096 512 1 mq-deadline 60 128 32M
Preventing Misaligned Partitions in the Future
From Linux Kernel 5.1 onwards the SCSI disk device driver rejects invalid optimal transfer sizes reported by disks  and writes a suitable warning into the kernel log. This fix should prevent those tools inadvertently creating any more misaligned partitions, but it does nothing for already created partitions which are misaligned. The most likely warning to occur is:
Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
 Why does fdisk insist on starting the first partition at sector 65535 (MiB 31.9995...)
 libfdisk: ignore misaligned optimal I/O size
 Why is Gnome Disk Utility (gnome-disks) skipping to a non-aligned start when creating a partition?
 Parted not properly auto aligning sectors for usb drive
 new hdd alignment issue, parted and fdisk aligning differently
 Debian bug #923561 - parted: Incorrect optimal alignment for USB device
 Linux SSD partition alignment - problems with external USB-to-SATA controllers - I
 Red Hat bug 1685787 - PV misalignment on UAS due to optimal_io_size not a multiple of physical_sector_size
 optimal_io_size is large causing LVM LV alignment inconsistency
 Red Hat bug 1513820 - lsblk -t reports alignment -1 for drive in a USB enclosure, alignment 512 when drive removed
 Ignore device opt-io alignment if it is not multiple of minimal-io.
 Linux SSD partition alignment - problems with external USB-to-SATA controllers - II
 Linux on 4KB-sector disks: Practical advice
 [linux-lvm] PE misalignment on USB UAS 512e drives kills performance
 Linux v5.1 scsi: sd: Optimal I/O size should be a multiple of physical block size
 Linux v5.0.4 scsi: sd: Optimal I/O size should be a multiple of physical block size
 Linux v4.19.13 scsi: sd: Optimal I/O size should be a multiple of physical block size
 Linux v4.15.108 scsi: sd: Optimal I/O size should be a multiple of physical block size
 Linux v4.9.165 scsi: sd: Optimal I/O size should be a multiple of physical block size
2019-Jun-08: Initial revision.
2019-Jun-11: Add fdisk as an affected tool.