On 02.07.2015 21:02, Phil Susi wrote:
>> BTW, "start and end are inclusive" - IMHO is very bad decision,
>> because now it is not possible to partition disk using MiB units
>> and always need use sectors and make all calculations manually.
>
> No.. MiB units work just fine.
I am just tested again on parted version 3.1
- it uses one more sector in case of "mib" unit.
>> for example, parted -s /dev/sda mkpart primary 34s 1MiB
>> now use one sector from second MiB and next partition
>> will be created as unaligned.
>
> No, it doesn't... the partition ends on sector 2047, so the next
> partition can start on sector 2048.
steps to reproduce bug:
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 34s 2047s 2014s primary bios_grub
2048s 67108822s 67106775s Free Space
if I issue command "mkpart primary 1MiB 8193MiB" - all works fine:
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 34s 2047s 2014s primary bios_grub
2 2048s 16779263s 16777216s primary
16779264s 67108822s 50329559s Free Space
but if I issue command "mkpart primary 1mib 8193mib" - BUG IS HERE:
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 34s 2047s 2014s primary bios_grub
2 2048s 16779264s 16777217s primary
16779265s 67108822s 50329558s Free Space
==============================================================
difference only in unit name case: 'MiB' works fine,
'mib' create wrong partitions, used one more sector.
looks like this is bug, and behavior of parted
should be the same, regardless of unit name case: 'mib' or 'MiB'.
--
Best regards,
Gena
