1

I am trying to partition a usb 3 drive but for some reason parted can't properly set the start sector. The drive is identical to multiple other sata drives, the only difference is that it's inside a usb 3 enclosure with 2 port hub integrated. I wouldn't have though it would matter.

Here are the steps I always used before:

sudo parted /dev/sd?
mklabel gpt
mkpart primary 0% 100%
quit

Here is fdisk -l output of the last 2 drives:

Disk /dev/sdk: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DB93D173-858A-475C-81CD-DB616E91C110

Device     Start         End     Sectors  Size Type
/dev/sdk1   2048 15628053134 15628051087  7.3T Linux filesystem


Disk /dev/sdl: 7.3 TiB, 8001563221504 bytes, 15628053167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: B3791850-76F8-4CE2-B1CC-DF40886292CE

Device     Start         End     Sectors  Size Type
/dev/sdl1  65535 15628000379 15627934845  7.3T Linux filesystem

Partition 1 does not start on physical sector boundary.

Second drive is the problematic one.

Performance really seems to take a big hit as formatting to ext4 takes a long time (never waited to finish) where normally it would only take seconds. Why is this happening? How can I get proper alignment?

The only other difference I can think of is that it was originally formatted as ntfs with some un-partitioned space. I also ran this command to clear any leftover partitions: dd if=/dev/zero of=/dev/sdl bs=512 count=10000 with no luck.

Using optimal alignment doesnt work either:

sudo parted -a optimal /dev/sdl mkpart primary 0% 100%


Warning: You requested a partition from 0.00B to 8002GB (sectors 0..15628053166).
The closest location we can manage is 17.4kB to 1048kB (sectors 34..2047).
Is this still acceptable to you?

2 Answers 2

2

The optimal I/O size of the second drive is much larger than that of the first one; that is probably what is causing the issue. This article from 2013 suggests to manually align partitions starting at (Optimal I/O + Alignment Offset) / Physical Block Size = starting slice, and reading how parted words nowadays it seems like this was rolled in to how parted works by default. Now, performing that math on your parameters returns 8191.875 as the starting slice, which is probably not a valid sector address.

It seems most likely to me that your USB enclosure is misrepresenting the optimal I/O of the drive. I would try manually specifying the starting sector as 2048, matching the first drive, when you make the partition try using mkpart primary 2048s 100%. That should work around it.

If you have the opportunity you can check this beforehand by plugging the drive into a computer without the USB enclosure and then checking /sys/block/[drive]/queue/optimal_io_size if it exists. If it doesn't match, the USB enclosure is probably misreporting the drive's capabilities.

6
  • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.
    – DominicM
    Commented Aug 24, 2017 at 20:37
  • There's nothing for you to check by connecting the drive directly to a SATA port. minimum/optimal_io_size is set from minimum/optimal transfer length in the block limits VPD. minimum/optimal transfer length isn't even a thing in ATA standard so technically there's nothing wrong for a UAS/USB-SATA bridge to report a value like 65535 (it might originate from the maximum length of a certain SCSI or ATA write command can cover).
    – Tom Yan
    Commented Aug 25, 2017 at 1:41
  • When you connect the drive to a SATA port, the job ("faking" the block limit VPD) goes to libata, which does not report an optimial i/o length (but only a minimum which is essentially physical block size divided by logical block size)
    – Tom Yan
    Commented Aug 25, 2017 at 1:41
  • 1
  • Partitioning works fine in another USB dock so it is indeed an issue with USB adapter. After partitioning and formatting fdisk -l gives "The backup GPT table is corrupt, but the primary appears OK, so that will be used." warning when used back in the original USB case.
    – DominicM
    Commented Aug 25, 2017 at 12:14
2

This was an issue in fdisk in util-linux. I reported to upstream quite sometime ago and it has been fixed:

https://github.com/karelzak/util-linux/commit/acb7651f8897ae73d0f45dd75bc87630001c61b9

So if you use fdisk in util-linux v2.27-rc1 or later to create partitions, you would not experience the problem.

I am not sure if parted has the same problem, if it does, it should probably introduce similar hack. (So file a bug report to upstream if you want to get it fixed: http://savannah.gnu.org/projects/parted/)

EDIT: Just notice that you are using GPT on both disks. IIRC gdisk does not suffer from this problem because it doesn't calculate alignment using the optimal i/o size, instead it statically defaults to 2048 and allows you to set it to any value range from 1 - 65536 (x -> l).

13
  • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.
    – DominicM
    Commented Aug 25, 2017 at 9:31
  • @DominicM what do you mean? Have you actually tried using fdisk to (re)create the partitions? I am not saying that it's a bug of fdisk -l. Have you misread? Note that parted has nothing to do with fdisk or util-linux.
    – Tom Yan
    Commented Aug 25, 2017 at 12:45
  • I thought you said earlier not later. In any case it's not fdisk as parted gave the warnings too. It turns out that Seagates USB controller is simply not competently designed making it impossible to partition properly.
    – DominicM
    Commented Aug 25, 2017 at 13:01
  • @DomonicM what warnings? I have no idea what you are talking about any more. FWIW I have UAS bridge that reports 65535 as optimal transfer length as well, partition aligning works fine with fdisk and gdisk. Seriously just give up parted, coz it sucks on every aspect and no longer have release cycle since 2014 (so it sucks even more unless you or your distro do a regular git build)
    – Tom Yan
    Commented Aug 25, 2017 at 13:28
  • 1
    @DominicM the best solution is to zap the GPT (both the primary and backup) and the PMBR with gdisk (x -> z -> y -> y), and create new partition table and new partition(s) with it from scratch. You won't even be aware of the optimal transfer length thing anymore.
    – Tom Yan
    Commented Aug 25, 2017 at 13:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .