bug#50168: closed (Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?))

[GNU bug Tracking System]

Your message dated Thu, 26 Aug 2021 14:42:31 -0700
with message-id <YSgKx6GaFgesT79q@ohop.brianlane.com>
and subject line Re: bug#50168: Inconsistent behavior creating partitions with 
'Xmib' and 'X%' (off-by-1 error?)
has caused the debbugs.gnu.org bug report #50168,
regarding Inconsistent behavior creating partitions with 'Xmib' and 'X%' 
(off-by-1 error?)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
50168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50168
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?) Date: Sun, 22 Aug 2021 19:59:06 +0200

[I'm not sure this is the appropriate place/way and if not, apologies, and can 
you point me to the right place/way]

Hi,

This is a forward of https://bugs.debian.org/988146 where I reported that 
partitions were created differently when using 'mib' unit vs '%' unit.

To demonstrate it, I created 3 scripts which creates a 100MB image and do the 
partitioning within that. 
When reporting the Debian bug, I only had the mixed test and 'parted-bug-test-
mixed.sh' is identical to the one attached here, apart from an 'else' clause 
which explicitly deletes a prior created image.

In parted-bug-test-mixed.sh, I mixed 'mib' and '%' and due to the 100MB, that 
should've worked, but it did not.

When using only 'mib' then the script fails too.
When using only '%' then the script succeeds.

I think parted does the right thing when using '%'.

Relevant portion of output when running the mixed script:
=======================================================
Creating partition table ... Done
Creating 1st partition ('4mib' '20%') ... Done
Creating 2nd partition ('20%' '40%' ... Done
Creating 3rd partition ('40mib' '60mib') ... Done

Showing partition layout
Disk temp/parted-test.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x03f77810

Device                Boot Start    End Sectors Size Id Type
temp/parted-test.img1       8192  40959   32768  16M  c W95 FAT32 (LBA)
temp/parted-test.img2      40960  81919   40960  20M 83 Linux
temp/parted-test.img3      81920 122880   40961  20M 83 Linux

Creating 4th partition ('60mib' '100%' ... Error: You requested a partition 
from 62,9MB to 105MB (sectors 122880..204799).
The closest location we can manage is 62,9MB to 105MB (sectors 
122881..204799).
=======================================================

Cheers,
  Diederik

parted-bug-test-mb.sh
Description: application/shellscript

parted-bug-test-perc.sh
Description: application/shellscript

parted-bug-test-mixed.sh
Description: application/shellscript

signature.asc
Description: This is a digitally signed message part.

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#50168: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?)
>
>
>
>
> Date: 
>
> Thu, 26 Aug 2021 14:42:31 -0700
>
>
>
>
> On Sun, Aug 22, 2021 at 07:59:06PM +0200, Diederik de Haas wrote:
> > This is a forward of https://bugs.debian.org/988146 where I reported that 
> > partitions were created differently when using 'mib' unit vs '%' unit.
>
> This list is where those bugs end up, so the first one made it :)
>
> > 
> > Creating 4th partition ('60mib' '100%' ... Error: You requested a partition 
> > from 62,9MB to 105MB (sectors 122880..204799).
> > The closest location we can manage is 62,9MB to 105MB (sectors 
> > 122881..204799).
>
> When you use MiB as a unit you are requesting an exact location, so this
> is telling you that sector 122880 (60*1024*1024) is already in use and
> it has to use the next sector instead. The other units use a snap
> algorithm with a radius of half the unit size (eg. 500k for MB) so it
> doesn't have this problem, and it is the default so that's why the
> output units are in MB.
>
> Brian
>
> -- 
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
>
>
>
> --- End Message ---