[Parted-maintainers] Bug#902224: parted: bogus rounding of exact sizes

[Adam Borowski]

On Mon, Jun 25, 2018 at 09:31:57AM -0400, Phillip Susi wrote:
> On 6/23/2018 11:12 AM, Adam Borowski wrote:
> > Start? 100mib                                                             
> > End? 100%                                                                 
> > Warning: You requested a partition from 100MiB to 14772MiB (sectors
> > 204800..30253055).
> > The closest location we can manage is 100MiB to 14772MiB (sectors
> > 204801..30253055).
> 
> This is because the first partition includes sector 204800 so the
> closest that can be allocated to the new partition is the next sector.
> This behavior has been changed upstream already by the following commit,
> which was released in parted 3.1, and so should be in debian, so I'm not
> sure why you are seeing it:

To exclude some oddity on arm64, I reproduced on amd64 using loop (as most
modern disks have sector sizes above 512 bytes otherwise):

# truncate -s 100G junk
# losetup -f junk
# parted /dev/loop0
GNU Parted 3.2
Using /dev/loop0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: /dev/loop0: unrecognised disk label
Model: Loopback device (loopback)
Disk /dev/loop0: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 
(parted) mklabel mbr
parted: invalid token: mbr
New disk label type? msdos
(parted) mkpart
Partition type?  primary/extended? p
File system type?  [ext2]?
Start? 1mib
End? 100mib
(parted) unit mib
(parted) mkpart
Partition type?  primary/extended? p
File system type?  [ext2]?
Start? 100mib
End? 100%
Warning: You requested a partition from 100MiB to 102400MiB (sectors 204800..209715199).
The closest location we can manage is 100MiB to 102400MiB (sectors 204801..209715199).
Is this still acceptable to you?
Yes/No? n

> commit 961abca12d1766264651dbe08284aeec3c0396c6
> Author: Petr Uzel <petr.uzel at suse.cz>
> Date:   Sat Oct 22 15:22:09 2011 +0200
> 
>     parted: mkpart: DWIM for IEC ending sector numbers like 2MiB and 9GiB
> 
>     Before, if the user specified start and end in mkpart command using
>     IEC units, parted created a partition that starts and ends exactly on
>     these positions. With such behavior, it is impossible to create
>     partitions as follows: 1MiB-2MiB, 2MiB-3MiB - parted would complain
>     that it cannot create the second partition, because the first one
>     occupied sectors 2048-4096 and the second one sectors 4096-3072,
>     so they would overlap at sector 4096.
> 
>     With this patch, if the user uses IEC units to specify end of the
>     partition, parted creates the partition which ends one sector before
>     the specified position.
> 
>     See also
>     https://lists.gnu.org/archive/html/bug-parted/2011-10/msg00009.html
> 
>     * parted/ui.c (command_line_get_sector): Add parameter to retrieve
>     raw input from user.
>     * parted/ui.h (command_line_get_sector): Adjust prototype of function.
>     * parted/parted.c (_adjust_end_if_iec): New function.
>     (_strip_trailing_spaces): New function.
>     (_string_ends_with_iec_unit): New function.
>     (do_mkpart): Call _adjust_end_if_iec(). Use new parameter of
>     command_line_get_sector function.
>     (do_rescue): Adjust call to command_line_get_sector.
>     * bootstrap.conf (gnulib_modules): Add these: c-ctype, c-strcase.
>     * tests/t0207-IEC-binary-notation.sh: Adjust to new semantics.
>     * NEWS: Mention the changed behavior.
> 
>     Notable adjustments:
>     - s/isspace/c_isblank/ so that parsing is locale-independent
>     - avoid an array-bounds error:
>       * parted/parted.c (_strip_trailing_spaces): Don't deref str[-1]
>       for an empty string.

It's especially puzzling that somehow "100mib" vs "102400kib" works
differently.  In light of the commit you quote, they both would have weird
[start..end] meaning before, and intuitively expected [start..end) after.
Also, "100%" end is interpreted as open, as expected.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄⠀⠀⠀⠀ go back and forth wrt their intended target.