GNU bug report logs - #25103
partition alignment

Previous Next

Package: parted;

Reported by: Volta <xvolta <at> gmail.com>

Date: Sun, 4 Dec 2016 04:40:01 UTC

Severity: normal

Done: Phil Susi <psusi <at> ubuntu.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-parted <at> gnu.org:
bug#25103; Package parted. (Sun, 04 Dec 2016 04:40:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Volta <xvolta <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-parted <at> gnu.org. (Sun, 04 Dec 2016 04:40:01 GMT) Full text and rfc822 format available.

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

From: Volta <xvolta <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: partition alignment
Date: Sun, 04 Dec 2016 01:54:33 +0000
[Message part 1 (text/plain, inline)]
I'm not sure if this is a bug in parted (parted 3.2 on Ubuntu 16.04.1LTS
x86-64), or a bug in my understanding of the concepts.  Either way I'd like
to know.

I've got a new 8TB drive for which the "optimal" alignment calculated by
parted doesn't satisfy the "minimal" alignment check. My understanding is
the "minimal" check verifies the partition is aligned to physical blocks on
the disk, so it seems impossible for an alignment that doesn't pass that
check to truly be "optimal".  Indeed, the documentation specifies "optimal"
is a aligned to a multiple of the physical block size.

For this drive, "--align opt" creates a partition starting at 65535s:

-- 8< --
$ sudo parted --align opt /dev/sdi mkpart 8tb ext4 0% 100% u s p free a min
1 a opt 1
Model: Seagate Expansion Desk (scsi)
Disk /dev/sdi: 15628053167s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start         End           Size          File system  Name  Flags
        34s           65534s        65501s        Free Space
 1      65535s        15628000379s  15627934845s  ext4         8tb
        15628000380s  15628053133s  52754s        Free Space

1 not aligned
1 aligned
-- 8< --

So, I fell back to how we used to do this, but the numbers are... weird:

-- 8< --
$ cat /sys/block/sdi/queue/optimal_io_size
33553920
$ cat /sys/block/sdi/queue/minimum_io_size
4096
$ cat /sys/block/sdi/queue/physical_block_size
4096
$ cat /sys/block/sdi/queue/logical_block_size
512
$ cat /sys/block/sdi/alignment_offset
0
-- 8< --

( 33553920 + 0 ) / 4096 = 8191.875, but that's not going to work. Using the
logical block size instead gives the 65535s that parted suggested, but if
my understanding is correct that's not actually a good alignment.

I can get a partition that satisfies both checks by scaling the 65535s out
to align with a 4k block, and starting the partition at 524280s, at the
cost of "wasting" ~300MiB of space:

-- 8< --
$ sudo parted --align opt /dev/sdi mkpart 8tb ext4 524280s 100% u s p free
a min 1 a opt 1
Model: Seagate Expansion Desk (scsi)
Disk /dev/sdi: 15628053167s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start         End           Size          File system  Name  Flags
        34s           524279s       524246s       Free Space
 1      524280s       15628000379s  15627476100s  ext4         8tb
        15628000380s  15628053133s  52754s        Free Space

1 aligned
1 aligned
-- 8< --

~300MiB out of 7.3TiB isn't the end of the world, so that's what I've gone
with for now, but I wonder if I'm not overthinking it.  Was parted's
original optimal alignment actually fine and my understanding incorrect? If
not, is there a better way than what I've done to calculate an alignment
that is?

For the near-term there's no data on this device so I'm perfectly happy to
burn it down for testing.

Thanks,

 -V

-- 8< --
$ sudo parted /dev/sdi print unit s print unit chs print
Model: Seagate Expansion Desk (scsi)
Disk /dev/sdi: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start  End     Size    File system  Name  Flags
 1      268MB  8002GB  8001GB               8tb

Model: Seagate Expansion Desk (scsi)
Disk /dev/sdi: 15628053167s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start    End           Size          File system  Name  Flags
 1      524280s  15628000379s  15627476100s               8tb

Model: Seagate Expansion Desk (scsi)
Disk /dev/sdi: 972801,80,61
Sector size (logical/physical): 512B/4096B
BIOS cylinder,head,sector geometry: 972801,255,63.  Each cylinder is 8225kB.
Partition Table: gpt
Disk Flags:

Number  Start      End         File system  Name  Flags
 1      32,161,57  972798,8,5               8tb
-- 8< --
[Message part 2 (text/html, inline)]

Information forwarded to bug-parted <at> gnu.org:
bug#25103; Package parted. (Sun, 04 Dec 2016 08:24:01 GMT) Full text and rfc822 format available.

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

From: Josep Lladonosa <jlladono <at> gmail.com>
To: Volta <xvolta <at> gmail.com>
Cc: 25103 <at> debbugs.gnu.org
Subject: Re: bug#25103: partition alignment
Date: Sun, 4 Dec 2016 07:55:37 +0100
[Message part 1 (text/plain, inline)]
On 4 Dec 2016 05:40, "Volta" <xvolta <at> gmail.com> wrote:
>
> I'm not sure if this is a bug in parted (parted 3.2 on Ubuntu 16.04.1LTS
x86-64), or a bug in my understanding of the concepts.  Either way I'd like
to know.
>
> I've got a new 8TB drive for which the "optimal" alignment calculated by
parted doesn't satisfy the "minimal" alignment check. My understanding is
the "minimal" check verifies the partition is aligned to physical blocks on
the disk, so it seems impossible for an alignment that doesn't pass that
check to truly be "optimal".  Indeed, the documentation specifies "optimal"
is a aligned to a multiple of the physical block size.
>
> For this drive, "--align opt" creates a partition starting at 65535s:
>
> -- 8< --
> $ sudo parted --align opt /dev/sdi mkpart 8tb ext4 0% 100% u s p free a
min 1 a opt 1
> Model: Seagate Expansion Desk (scsi)
> Disk /dev/sdi: 15628053167s
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start         End           Size          File system  Name  Flags
>         34s           65534s        65501s        Free Space
>  1      65535s        15628000379s  15627934845s  ext4         8tb
>         15628000380s  15628053133s  52754s        Free Space
>
> 1 not aligned
> 1 aligned
> -- 8< --
>
> So, I fell back to how we used to do this, but the numbers are... weird:
>
> -- 8< --
> $ cat /sys/block/sdi/queue/optimal_io_size
> 33553920

Maybe this value is not drive related but usb bus related. Is that a usb
drive? I guess so. Found similar cases. One of them:

https://www.mail-archive.com/search?l=linux-usb <at> vger.kernel.org&q=subject:%22Re%5C%3A+questions+about+uas%22&o=newest&f=1


> $ cat /sys/block/sdi/queue/minimum_io_size
> 4096
> $ cat /sys/block/sdi/queue/physical_block_size
> 4096
> $ cat /sys/block/sdi/queue/logical_block_size
> 512
> $ cat /sys/block/sdi/alignment_offset
> 0
> -- 8< --
>
> ( 33553920 + 0 ) / 4096 = 8191.875, but that's not going to work. Using
the logical block size instead gives the 65535s that parted suggested, but
if my understanding is correct that's not actually a good alignment.
>
> I can get a partition that satisfies both checks by scaling the 65535s
out to align with a 4k block, and starting the partition at 524280s, at the
cost of "wasting" ~300MiB of space:
>
> -- 8< --
> $ sudo parted --align opt /dev/sdi mkpart 8tb ext4 524280s 100% u s p
free a min 1 a opt 1
> Model: Seagate Expansion Desk (scsi)
> Disk /dev/sdi: 15628053167s
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start         End           Size          File system  Name  Flags
>         34s           524279s       524246s       Free Space
>  1      524280s       15628000379s  15627476100s  ext4         8tb
>         15628000380s  15628053133s  52754s        Free Space
>
> 1 aligned
> 1 aligned
> -- 8< --
>
> ~300MiB out of 7.3TiB isn't the end of the world, so that's what I've
gone with for now, but I wonder if I'm not overthinking it.  Was parted's
original optimal alignment actually fine and my understanding incorrect? If
not, is there a better way than what I've done to calculate an alignment
that is?
>
> For the near-term there's no data on this device so I'm perfectly happy
to burn it down for testing.
>
> Thanks,
>
>  -V
>
> -- 8< --
> $ sudo parted /dev/sdi print unit s print unit chs print
> Model: Seagate Expansion Desk (scsi)
> Disk /dev/sdi: 8002GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start  End     Size    File system  Name  Flags
>  1      268MB  8002GB  8001GB               8tb
>
> Model: Seagate Expansion Desk (scsi)
> Disk /dev/sdi: 15628053167s
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags:
>
> Number  Start    End           Size          File system  Name  Flags
>  1      524280s  15628000379s  15627476100s               8tb
>
> Model: Seagate Expansion Desk (scsi)
> Disk /dev/sdi: 972801,80,61
> Sector size (logical/physical): 512B/4096B
> BIOS cylinder,head,sector geometry: 972801,255,63.  Each cylinder is
8225kB.
> Partition Table: gpt
> Disk Flags:
>
> Number  Start      End         File system  Name  Flags
>  1      32,161,57  972798,8,5               8tb
> -- 8< --
[Message part 2 (text/html, inline)]

Information forwarded to bug-parted <at> gnu.org:
bug#25103; Package parted. (Sun, 04 Dec 2016 20:16:02 GMT) Full text and rfc822 format available.

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

From: Volta <xvolta <at> gmail.com>
To: Josep Lladonosa <jlladono <at> gmail.com>
Cc: 25103 <at> debbugs.gnu.org
Subject: Re: bug#25103: partition alignment
Date: Sun, 4 Dec 2016 15:14:56 -0500
On 4 December 2016 at 01:55, Josep Lladonosa <jlladono <at> gmail.com> wrote:
> On 4 Dec 2016 05:40, "Volta" <xvolta <at> gmail.com> wrote:
>> 1 not aligned
>> 1 aligned
>> -- 8< --
>>
>> So, I fell back to how we used to do this, but the numbers are... weird:
>>
>> -- 8< --
>> $ cat /sys/block/sdi/queue/optimal_io_size
>> 33553920
>
> Maybe this value is not drive related but usb bus related. Is that a usb
> drive? I guess so. Found similar cases. One of them:
>
> https://www.mail-archive.com/search?l=linux-usb <at> vger.kernel.org&q=subject:%22Re%5C%3A+questions+about+uas%22&o=newest&f=1

Interesting! Yes, as you've guessed, it is a USB drive, using the uas
driver. So, not a parted bug, and I've got a new avenue to read up on.

Thank you!

 -V




Reply sent to Phil Susi <psusi <at> ubuntu.com>:
You have taken responsibility. (Wed, 19 Apr 2017 14:30:08 GMT) Full text and rfc822 format available.

Notification sent to Volta <xvolta <at> gmail.com>:
bug acknowledged by developer. (Wed, 19 Apr 2017 14:30:08 GMT) Full text and rfc822 format available.

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

From: Phil Susi <psusi <at> ubuntu.com>
To: Volta <xvolta <at> gmail.com>, Josep Lladonosa <jlladono <at> gmail.com>
Cc: 25103-done <at> debbugs.gnu.org
Subject: Re: bug#25103: partition alignment
Date: Wed, 19 Apr 2017 10:30:45 -0400
On 12/4/2016 3:14 PM, Volta wrote:
> On 4 December 2016 at 01:55, Josep Lladonosa <jlladono <at> gmail.com> wrote:
>> Maybe this value is not drive related but usb bus related. Is that a usb
>> drive? I guess so. Found similar cases. One of them:
>>
>> https://www.mail-archive.com/search?l=linux-usb <at> vger.kernel.org&q=subject:%22Re%5C%3A+questions+about+uas%22&o=newest&f=1
> 
> Interesting! Yes, as you've guessed, it is a USB drive, using the uas
> driver. So, not a parted bug, and I've got a new avenue to read up on.

Interesting, but yes, parted is simply respecting the fubar optimal IO
size this drive is reporting, which appears to be one sector less than
32 mb.  Normal drives have an optimal IO size of 32 kb.






bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 18 May 2017 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 35 days ago.

Previous Next


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