GNU bug report logs - #36908
parted optimal alignment fails minimal alignment check

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36908 in the body.
You can then email your comments to 36908 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: George Fedorov <gfedorov <at> unimelb.edu.au>
To: "bug-parted <at> gnu.org" <bug-parted <at> gnu.org>
Subject: parted optimal alignment fails minimal alignment check
Date: Sat, 3 Aug 2019 12:26:56 +0000

[Message part 1 (text/plain, inline)]

Hi,


I was directed here by the page at https://www.gnu.org/software/parted/bugs.shtml ; is there any bugreport tracker where one can file a bug instead ?


Anyway, here's the problem ( manifested in parted 3.2 coming with Ubuntu 18.04 and checked vs. a manual build of the sources from http://ftp.gnu.org/gnu/parted/parted-3.2.tar.xz  ):


=== parted version ===


# parted --version
parted (GNU parted) 3.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by <http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.

=== print unit s print unit chs print ===


# parted /dev/sdi print unit s print unit chs print
Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End  Size  File system  Name  Flags

Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 5860533168s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End  Size  File system  Name  Flags

Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 364801,80,62
Sector size (logical/physical): 512B/512B
BIOS cylinder,head,sector geometry: 364801,255,63.  Each cylinder is 8225kB.
Partition Table: gpt
Disk Flags:

Number  Start  End  File system  Name  Flags


=== the problem ===


# parted /dev/sdi
GNU Parted 3.2
Using /dev/sdi
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mkpart test1 0% 1T
(parted) unit B
(parted) print
Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 3000592982016B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start      End             Size           File system  Name   Flags
 1      33553920B  1000007477759B  999973923840B               test1

(parted) align-check optimal 1
1 aligned
(parted) align-check minimal 1
1 not aligned
(parted)


=====


First of all, start sector value looks insanely big for "0%" ; second, one would imagine that passing an optimal check would imply passing a minimal check.


If one tries to start at e.g. 1 MiB, then of course the optimal check will not pass :


=====

# parted /dev/sdi
GNU Parted 3.2
Using /dev/sdi
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End  Size  File system  Name  Flags

(parted) mkpart test1 ext2 2048s 1T
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? I
(parted) unit B
(parted) print
Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
Disk /dev/sdi: 3000592982016B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start     End             Size           File system  Name   Flags
 1      1048576B  1000000000511B  999998951936B  ext2         test1

(parted) align-check optimal 1
1 not aligned
(parted) align-check minimal 1
1 aligned


=====


As it turns out, the root of all evil comes from here :


=====

# cat /sys/block/sdi/queue/optimal_io_size
33553920
=====


So parted is not to blame, but the system. But from the user's point of view, it is quite hard to figure this out. And certainly the user deserves to know the actual values that parted considers to be of best performance -- I mean, pa->offset and pa->grain_size from parted.c::print_partition_alignment() shall probably be exposed in some way -- at least when it comes to a warning like the one above.



Kind regards
Georgy Fedorov
Senior Systems Specialist
Melbourne School of Engineering
The University of Melbourne, Victoria 3010, Australia
email: gfedorov <at> unimelb.edu.au<mailto:gfedorov <at> unimelb.edu.au>
http://www.eng.unimelb.edu.au

<https://owa.unimelb.edu.au/owa/redir.aspx?SURL=zZ66u8zSk7WjNEV9pSzLYdWdXh0cvHwxj-uz4bP1rcBS-JFIAfjRCGgAdAB0AHAAOgAvAC8AdwB3AHcALgBlAG4AZwAuAHUAbgBpAG0AZQBsAGIALgBlAGQAdQAuAGEAdQAvAA..&URL=http%3a%2f%2fwww.eng.unimelb.edu.au%2f>

[Message part 2 (text/html, inline)]

Message #8 received at 36908 <at> debbugs.gnu.org (full text, mbox):

From: Volta <xvolta <at> gmail.com>
To: George Fedorov <gfedorov <at> unimelb.edu.au>
Cc: 36908 <at> debbugs.gnu.org
Subject: Re: bug#36908: parted optimal alignment fails minimal alignment check
Date: Sat, 3 Aug 2019 12:15:01 -0400

I'm not a parted dev, just a user, but I've run into this same issue
several times.  This wouldn't happen to be a USB device using the UAS
driver? IME setting quirks mode for such devices so they use the
usb-storage driver instead yields sensible values for optimal_io_size,
etc. so parted can do the right thing with 0% and properly align the
partitions.  This also works around other issues I've had with these
devices randomly disconnecting when using UAS. My
/etc/modprobe.d/usbdisks.conf file contains:

options usb-storage
quirks=0x0bc2:0xab31:u,0x0bc2:0x3322:u,0x0bc2:0xa0a4:u,0x0bc2:0x331a:u,0x0bc2:3343:u

get the device identifiers for the affected device(s) from lsusb,
stick them in there, then 'depmod -a' and reboot or remove and
reattach the device(s) (the latter should work, but sometimes the
kernel doesn't do the right thing, and I've not bothered to
investigate further as I only use USB disks on workstations that are
easily rebooted), then try parted again.

Doesn't really "solve" the problem, which I understand to be with the
UAS implementation in these devices, but at least it is a usable
workaround.

On Sat, 3 Aug 2019 at 11:18, George Fedorov <gfedorov <at> unimelb.edu.au> wrote:
>
> Hi,
>
>
> I was directed here by the page at https://www.gnu.org/software/parted/bugs.shtml ; is there any bugreport tracker where one can file a bug instead ?
>
>
> Anyway, here's the problem ( manifested in parted 3.2 coming with Ubuntu 18.04 and checked vs. a manual build of the sources from http://ftp.gnu.org/gnu/parted/parted-3.2.tar.xz  ):
>
>
> === parted version ===
>
>
> # parted --version
> parted (GNU parted) 3.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by <http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.
>
> === print unit s print unit chs print ===
>
>
> # parted /dev/sdi print unit s print unit chs print
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 3001GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start  End  Size  File system  Name  Flags
>
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 5860533168s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start  End  Size  File system  Name  Flags
>
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 364801,80,62
> Sector size (logical/physical): 512B/512B
> BIOS cylinder,head,sector geometry: 364801,255,63.  Each cylinder is 8225kB.
> Partition Table: gpt
> Disk Flags:
>
> Number  Start  End  File system  Name  Flags
>
> === the problem ===
>
>
> # parted /dev/sdi
> GNU Parted 3.2
> Using /dev/sdi
> Welcome to GNU Parted! Type 'help' to view a list of commands.
> (parted) mkpart test1 0% 1T
> (parted) unit B
> (parted) print
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 3000592982016B
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start      End             Size           File system  Name   Flags
>  1      33553920B  1000007477759B  999973923840B               test1
>
> (parted) align-check optimal 1
> 1 aligned
> (parted) align-check minimal 1
> 1 not aligned
> (parted)
>
>
> =====
>
>
> First of all, start sector value looks insanely big for "0%" ; second, one would imagine that passing an optimal check would imply passing a minimal check.
>
>
> If one tries to start at e.g. 1 MiB, then of course the optimal check will not pass :
>
>
> =====
>
> # parted /dev/sdi
> GNU Parted 3.2
> Using /dev/sdi
> Welcome to GNU Parted! Type 'help' to view a list of commands.
> (parted) print
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 3001GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start  End  Size  File system  Name  Flags
>
> (parted) mkpart test1 ext2 2048s 1T
> Warning: The resulting partition is not properly aligned for best performance.
> Ignore/Cancel? I
> (parted) unit B
> (parted) print
> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
> Disk /dev/sdi: 3000592982016B
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start     End             Size           File system  Name   Flags
>  1      1048576B  1000000000511B  999998951936B  ext2         test1
>
> (parted) align-check optimal 1
> 1 not aligned
> (parted) align-check minimal 1
> 1 aligned
>
> =====
>
>
> As it turns out, the root of all evil comes from here :
>
>
> =====
>
> # cat /sys/block/sdi/queue/optimal_io_size
> 33553920
> =====
>
> So parted is not to blame, but the system. But from the user's point of view, it is quite hard to figure this out. And certainly the user deserves to know the actual values that parted considers to be of best performance -- I mean, pa->offset and pa->grain_size from parted.c::print_partition_alignment() shall probably be exposed in some way -- at least when it comes to a warning like the one above.
>
>
>
>
> Kind regards
> Georgy Fedorov
> Senior Systems Specialist
> Melbourne School of Engineering
> The University of Melbourne, Victoria 3010, Australia
> email: gfedorov <at> unimelb.edu.au
> http://www.eng.unimelb.edu.au
>

Message #13 received at 36908-done <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: George Fedorov <gfedorov <at> unimelb.edu.au>
Cc: 36908-done <at> debbugs.gnu.org
Subject: Re: bug#36908: parted optimal alignment fails minimal alignment check
Date: Mon, 5 Aug 2019 09:01:09 -0700

On Sat, Aug 03, 2019 at 12:26:56PM +0000, George Fedorov wrote:
> Hi,
> 
> 
> I was directed here by the page at https://www.gnu.org/software/parted/bugs.shtml ; is there any bugreport tracker where one can file a bug instead ?
> 
> 
> Anyway, here's the problem ( manifested in parted 3.2 coming with Ubuntu 18.04 and checked vs. a manual build of the sources from http://ftp.gnu.org/gnu/parted/parted-3.2.tar.xz  ):


The 3.2 tar is *really* old at this point and should not really be used.

[snip]


> As it turns out, the root of all evil comes from here :
> 
> 
> =====
> 
> # cat /sys/block/sdi/queue/optimal_io_size
> 33553920
> =====
> 
> 
> So parted is not to blame, but the system. But from the user's point of view, it is quite hard to figure this out. And certainly the user deserves to know the actual values that parted considers to be of best performance -- I mean, pa->offset and pa->grain_size from parted.c::print_partition_alignment() shall probably be exposed in some way -- at least when it comes to a warning like the one above.


In commit 1726dbb4cd2dc4b19fe8d3c4b94e172fc0bd2c7c I added a message
that describes the failure with a bit more detail. It will print
something like:

<start> % <grain_size> != <offset>

I'm guessing Ubuntu doesn't have that patch, and the 3.2 tarball is
getting *really* old at this point (which is why I'm working toward a
3.3 release soon).

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted

Message #16 received at 36908 <at> debbugs.gnu.org (full text, mbox):

From: Georgy Fedorov <gfedorov <at> unimelb.edu.au>
To: "Brian C. Lane" <bcl <at> redhat.com>
Cc: 36908 <at> debbugs.gnu.org, 36908-done <at> debbugs.gnu.org
Subject: Re: bug#36908: parted optimal alignment fails minimal alignment check
Date: Tue, 6 Aug 2019 15:45:12 +1000

[Message part 1 (text/plain, inline)]

Perfect! That's exactly what I had in mind.

As for the version -- I have noticed that the most recent release at 
ftp.gnu.org/gnu/parted is a little old -- but it still was the most 
recent release, so I went with that. My apologies.

Kind regards, George


On 6/8/19 2:01 am, Brian C. Lane wrote:
> On Sat, Aug 03, 2019 at 12:26:56PM +0000, George Fedorov wrote:
>> Hi,
>>
>>
>> I was directed here by the page at https://protect-au.mimecast.com/s/FpF4C91ZVBSnZ5nYsoexuZ?domain=gnu.org ; is there any bugreport tracker where one can file a bug instead ?
>>
>>
>> Anyway, here's the problem ( manifested in parted 3.2 coming with Ubuntu 18.04 and checked vs. a manual build of the sources from https://protect-au.mimecast.com/s/Kz_DC0YZJpCvERvrcDJs5C?domain=ftp.gnu.org  ):
>
> The 3.2 tar is *really* old at this point and should not really be used.
>
> [snip]
>
>
>> As it turns out, the root of all evil comes from here :
>>
>>
>> =====
>>
>> # cat /sys/block/sdi/queue/optimal_io_size
>> 33553920
>> =====
>>
>>
>> So parted is not to blame, but the system. But from the user's point of view, it is quite hard to figure this out. And certainly the user deserves to know the actual values that parted considers to be of best performance -- I mean, pa->offset and pa->grain_size from parted.c::print_partition_alignment() shall probably be exposed in some way -- at least when it comes to a warning like the one above.
>
> In commit 1726dbb4cd2dc4b19fe8d3c4b94e172fc0bd2c7c I added a message
> that describes the failure with a bit more detail. It will print
> something like:
>
> <start> % <grain_size> != <offset>
>
> I'm guessing Ubuntu doesn't have that patch, and the 3.2 tarball is
> getting *really* old at this point (which is why I'm working toward a
> 3.3 release soon).
>
> Brian
>

-- 
George Fedorov
Senior Systems Specialist
Melbourne School of Engineering
The University of Melbourne, Victoria 3010, Australia
email: gfedorov <at> unimelb.edu.au
http://www.eng.unimelb.edu.au/

[Message part 2 (text/html, inline)]

Message #19 received at 36908 <at> debbugs.gnu.org (full text, mbox):

From: Georgy Fedorov <gfedorov <at> unimelb.edu.au>
To: Volta <xvolta <at> gmail.com>
Cc: 36908 <at> debbugs.gnu.org
Subject: Re: bug#36908: parted optimal alignment fails minimal alignment check
Date: Tue, 6 Aug 2019 16:08:32 +1000

[Message part 1 (text/plain, inline)]

Thank you -- that's a very good point.

Just in case if this thread would get indexed, I would add a reference 
for usb-storage quirks:
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html 
( search for "usb-storage.quirks=" )

Kind regards, George

On 4/8/19 2:15 am, Volta wrote:
> I'm not a parted dev, just a user, but I've run into this same issue
> several times.  This wouldn't happen to be a USB device using the UAS
> driver? IME setting quirks mode for such devices so they use the
> usb-storage driver instead yields sensible values for optimal_io_size,
> etc. so parted can do the right thing with 0% and properly align the
> partitions.  This also works around other issues I've had with these
> devices randomly disconnecting when using UAS. My
> /etc/modprobe.d/usbdisks.conf file contains:
>
> options usb-storage
> quirks=0x0bc2:0xab31:u,0x0bc2:0x3322:u,0x0bc2:0xa0a4:u,0x0bc2:0x331a:u,0x0bc2:3343:u
>
> get the device identifiers for the affected device(s) from lsusb,
> stick them in there, then 'depmod -a' and reboot or remove and
> reattach the device(s) (the latter should work, but sometimes the
> kernel doesn't do the right thing, and I've not bothered to
> investigate further as I only use USB disks on workstations that are
> easily rebooted), then try parted again.
>
> Doesn't really "solve" the problem, which I understand to be with the
> UAS implementation in these devices, but at least it is a usable
> workaround.
>
> On Sat, 3 Aug 2019 at 11:18, George Fedorov <gfedorov <at> unimelb.edu.au> wrote:
>> Hi,
>>
>>
>> I was directed here by the page at https://protect-au.mimecast.com/s/yFf9CWLJMvF3vx10s6x6jT?domain=gnu.org ; is there any bugreport tracker where one can file a bug instead ?
>>
>>
>> Anyway, here's the problem ( manifested in parted 3.2 coming with Ubuntu 18.04 and checked vs. a manual build of the sources from https://protect-au.mimecast.com/s/b7SyCXLKNwFA3GlmTVBluL?domain=ftp.gnu.org  ):
>>
>>
>> === parted version ===
>>
>>
>> # parted --version
>> parted (GNU parted) 3.2
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <https://protect-au.mimecast.com/s/wE-3CYWLOxhYPgK5s9N9ZR?domain=gnu.org>.
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>> Written by <https://protect-au.mimecast.com/s/T3hlCZYMPyCvyx1zcygnbo?domain=git.debian.org>.
>>
>> === print unit s print unit chs print ===
>>
>>
>> # parted /dev/sdi print unit s print unit chs print
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 3001GB
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start  End  Size  File system  Name  Flags
>>
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 5860533168s
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start  End  Size  File system  Name  Flags
>>
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 364801,80,62
>> Sector size (logical/physical): 512B/512B
>> BIOS cylinder,head,sector geometry: 364801,255,63.  Each cylinder is 8225kB.
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start  End  File system  Name  Flags
>>
>> === the problem ===
>>
>>
>> # parted /dev/sdi
>> GNU Parted 3.2
>> Using /dev/sdi
>> Welcome to GNU Parted! Type 'help' to view a list of commands.
>> (parted) mkpart test1 0% 1T
>> (parted) unit B
>> (parted) print
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 3000592982016B
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start      End             Size           File system  Name   Flags
>>   1      33553920B  1000007477759B  999973923840B               test1
>>
>> (parted) align-check optimal 1
>> 1 aligned
>> (parted) align-check minimal 1
>> 1 not aligned
>> (parted)
>>
>>
>> =====
>>
>>
>> First of all, start sector value looks insanely big for "0%" ; second, one would imagine that passing an optimal check would imply passing a minimal check.
>>
>>
>> If one tries to start at e.g. 1 MiB, then of course the optimal check will not pass :
>>
>>
>> =====
>>
>> # parted /dev/sdi
>> GNU Parted 3.2
>> Using /dev/sdi
>> Welcome to GNU Parted! Type 'help' to view a list of commands.
>> (parted) print
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 3001GB
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start  End  Size  File system  Name  Flags
>>
>> (parted) mkpart test1 ext2 2048s 1T
>> Warning: The resulting partition is not properly aligned for best performance.
>> Ignore/Cancel? I
>> (parted) unit B
>> (parted) print
>> Model: WDC WD30 EZRZ-00Z5HB0 (scsi)
>> Disk /dev/sdi: 3000592982016B
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start     End             Size           File system  Name   Flags
>>   1      1048576B  1000000000511B  999998951936B  ext2         test1
>>
>> (parted) align-check optimal 1
>> 1 not aligned
>> (parted) align-check minimal 1
>> 1 aligned
>>
>> =====
>>
>>
>> As it turns out, the root of all evil comes from here :
>>
>>
>> =====
>>
>> # cat /sys/block/sdi/queue/optimal_io_size
>> 33553920
>> =====
>>
>> So parted is not to blame, but the system. But from the user's point of view, it is quite hard to figure this out. And certainly the user deserves to know the actual values that parted considers to be of best performance -- I mean, pa->offset and pa->grain_size from parted.c::print_partition_alignment() shall probably be exposed in some way -- at least when it comes to a warning like the one above.
>>
>>
>>
>>
>> Kind regards
>> Georgy Fedorov
>> Senior Systems Specialist
>> Melbourne School of Engineering
>> The University of Melbourne, Victoria 3010, Australia
>> email: gfedorov <at> unimelb.edu.au
>> http://www.eng.unimelb.edu.au
>>

-- 
George Fedorov
Senior Systems Specialist
Melbourne School of Engineering
The University of Melbourne, Victoria 3010, Australia
email: gfedorov <at> unimelb.edu.au
http://www.eng.unimelb.edu.au/

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.