Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?
On Wed 04 Dec 2019 at 13:15:51 (+0100), Sergey Spiridonov wrote:
> I am trying to partition 14TB HDD and get the following problem with an
> alignment:
>
> # hdparam -I /dev/sdd tells that
>
> Logical Sector size: 512 bytes
> Physical Sector size: 4096 bytes
>
> # parted -a opt /dev/sdd
>
> (parted) mkpart primary 0% 100%
> ...
> (parted) print
>
> Number Start End Size File system Name Flags
> 1 33,6MB 14,0TB 14,0TB primary
>
> Now checking alignment:
>
> (parted) align-check opt
> 1 1 aligned
>
> So far, so good. Now let's look at the same disk with fdisk:
>
> # fdisk /dev/sdd
> : p
>
> Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors
> Disk model: IB-366StU3+B
> 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: gpt
> Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26
>
> Device Start End Sectors Size Type
> /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem
>
> Partition 1 does not start on physical sector boundary.
>
> What? Why?
> man parted tells that
>
> optimal
> Use optimum alignment as given by the disk
> topology in‐ formation. This aligns to a
> multiple of the physical block size in a way that
> guarantees optimal performance
>
> 1. Probably parted detected physical sector size as 512
> instead of 4096? Why?
>
> 2. Even if parted thinks that physical sector is 512 instead of
> 4096, why start from 65535 and not from 65536? What is the logic
> behind? How using odd multiplier can improve performance?
>
> Is it a bug in parted or I am missing something?
Bug #923561 has a long discussion about alignment and optimal transfer
size, and it would appear to be a bit of a mess, with no conclusion on
the root cause of the problem, how to document it, or which software
should deal with it (as best I can understand it).
I think the straightforward way of coping with this is to use the
"unit s" command (so that sectors are the default unit), and then
create the partition with something like:
(parted) mkpart primary 2048s 100%
ie give an explicit alignment.
(I've always used gdisk for creating partitions ever since GPT disks
came on the scene, worked in sectors, and relied on gdisk to calculate
the last sector number.)
Regardless of the partitioning, I see messages like:
Optimal transfer size 33553920 bytes not a multiple of physical block size (2048 bytes)
Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Optimal transfer size 268431360 bytes not a multiple of physical block size (16384 bytes)
in the kernel log when I plug some of my disks in. Adding to the
mystery, the first two messages quoted here were given by the same
1TB disk. fdisk agrees with 4096 as the physical block size.
This leads me to ignore the transfer size, let alone calculate
anything from it.
Cheers,
David.
Reply to: