A few comments for the "look forward to having that all explained to me" part.
As already identified the message is from parted as a warning, not something like mdadm/lvm/dm that actually detect a real issue (yet).
At the core of the check it does:
ok = (part->geom.start % pa->grain_size == pa->offset);
Attributes of "part" are our configuration and "pa" are disk attributes it derives disk attributes.
Parted defines:
ped_device_get_minimum_alignment
ped_device_get_optimum_alignment
The values it considers are from /sys/block/<disk>/queue/
The workaround of "1 compact" works because compact it is defined as:
"This is a special unit that defaults to megabytes for input, and picks a unit that gives a compact human readable representation for output."
That means "1 compact" translates into "1 MB" which is a good alignment for the usual values of 4k or so.
In fact >=1M is parteds default expected value for "good" alignment if it has no further disk information.
I can reproduce and test the behaviour with almost any current block testcase we have. in curtin vmtests
In there curtin just does what it is told - no magic to avoid alignment issues there.
So the following yaml translates to the latter commands:
- id: sda
type: disk
ptable: msdos
model: QEMU HARDDISK
path: /dev/vdb
name: main_disk
- id: sda1
type: partition
size: 3GB
device: sda
flag: boot
- id: sda_extended
type: partition
size: 5G
flag: extended
device: sda
- id: sda2
type: partition
size: 2G
flag: logical
device: sda
- id: sda3
type: partition
size: 2G
flag: logical
device: sda
Running command ['parted', '/dev/vdb', '--script', 'mklabel', 'msdos'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'primary', '2048s', '6293504s'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'extended', '6293506s', '16779266s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '6293509s', '10487813s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '10487815s', '14682119s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Curtin starts the first partition at 1 MB and ends at 1MB+Size
In our example we requested 3GB
START of 1st Partition = 2048
END => 2048+((2**30)*3/512)
So the partition goes 2048s to 6293504s
Note ((6293504-2048)*512)/(2**30) = 3GB
If the config is rather vague like in the example above we might try to auto-align in curtin at the cost of some space.
As soon as the yaml from maas will contain sector specifications curtin has to obey these orders.
Also as Blake pointed out MAAS could "overalign" at e.g. 4MB to always be on the safe side - and if MAAS specifies sectors is the only way.
A few comments for the "look forward to having that all explained to me" part.
As already identified the message is from parted as a warning, not something like mdadm/lvm/dm that actually detect a real issue (yet).
At the core of the check it does:
ok = (part->geom.start % pa->grain_size == pa->offset);
Attributes of "part" are our configuration and "pa" are disk attributes it derives disk attributes.
Parted defines: get_minimum_ alignment get_optimum_ alignment <disk>/ queue/
ped_device_
ped_device_
The values it considers are from /sys/block/
The workaround of "1 compact" works because compact it is defined as:
"This is a special unit that defaults to megabytes for input, and picks a unit that gives a compact human readable representation for output."
That means "1 compact" translates into "1 MB" which is a good alignment for the usual values of 4k or so.
In fact >=1M is parteds default expected value for "good" alignment if it has no further disk information.
I can reproduce and test the behaviour with almost any current block testcase we have. in curtin vmtests
In there curtin just does what it is told - no magic to avoid alignment issues there.
So the following yaml translates to the latter commands:
- id: sda
type: disk
ptable: msdos
model: QEMU HARDDISK
path: /dev/vdb
name: main_disk
- id: sda1
type: partition
size: 3GB
device: sda
flag: boot
- id: sda_extended
type: partition
size: 5G
flag: extended
device: sda
- id: sda2
type: partition
size: 2G
flag: logical
device: sda
- id: sda3
type: partition
size: 2G
flag: logical
device: sda
Running command ['parted', '/dev/vdb', '--script', 'mklabel', 'msdos'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'primary', '2048s', '6293504s'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'extended', '6293506s', '16779266s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '6293509s', '10487813s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '10487815s', '14682119s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Curtin starts the first partition at 1 MB and ends at 1MB+Size 2**30)* 3/512) 2048)*512) /(2**30) = 3GB
In our example we requested 3GB
START of 1st Partition = 2048
END => 2048+((
So the partition goes 2048s to 6293504s
Note ((6293504-
If the config is rather vague like in the example above we might try to auto-align in curtin at the cost of some space.
As soon as the yaml from maas will contain sector specifications curtin has to obey these orders.
Also as Blake pointed out MAAS could "overalign" at e.g. 4MB to always be on the safe side - and if MAAS specifies sectors is the only way.