Parted not properly auto aligning sectors for usb drive












0















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?









share|improve this question
















bumped to the homepage by Community 14 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    0















    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?









    share|improve this question
















    bumped to the homepage by Community 14 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      0












      0








      0








      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?









      share|improve this question
















      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?






      filesystems partition parted






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 24 '17 at 18:47







      DominicM

















      asked Aug 24 '17 at 17:46









      DominicMDominicM

      254621




      254621





      bumped to the homepage by Community 14 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 14 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          2 Answers
          2






          active

          oldest

          votes


















          0














          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.






          share|improve this answer
























          • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

            – DominicM
            Aug 24 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 1:41








          • 1





            Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

            – Tom Yan
            Aug 25 '17 at 1:43













          • 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
            Aug 25 '17 at 12:14



















          0














          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).






          share|improve this answer


























          • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

            – DominicM
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 13:28











          • @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
            Aug 25 '17 at 13:38











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f388157%2fparted-not-properly-auto-aligning-sectors-for-usb-drive%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          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.






          share|improve this answer
























          • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

            – DominicM
            Aug 24 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 1:41








          • 1





            Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

            – Tom Yan
            Aug 25 '17 at 1:43













          • 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
            Aug 25 '17 at 12:14
















          0














          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.






          share|improve this answer
























          • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

            – DominicM
            Aug 24 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 1:41








          • 1





            Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

            – Tom Yan
            Aug 25 '17 at 1:43













          • 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
            Aug 25 '17 at 12:14














          0












          0








          0







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Aug 24 '17 at 20:09









          ThegsThegs

          31516




          31516













          • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

            – DominicM
            Aug 24 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 1:41








          • 1





            Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

            – Tom Yan
            Aug 25 '17 at 1:43













          • 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
            Aug 25 '17 at 12:14



















          • I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

            – DominicM
            Aug 24 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 1:41








          • 1





            Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

            – Tom Yan
            Aug 25 '17 at 1:43













          • 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
            Aug 25 '17 at 12:14

















          I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

          – DominicM
          Aug 24 '17 at 20:37







          I did try "mkpart primary 2048s 100%" but same warnings still. Will try to break into the case next.

          – DominicM
          Aug 24 '17 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
          Aug 25 '17 at 1:41





          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
          Aug 25 '17 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
          Aug 25 '17 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
          Aug 25 '17 at 1:41






          1




          1





          Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

          – Tom Yan
          Aug 25 '17 at 1:43







          Relevant code in the kernel: elixir.free-electrons.com/linux/v4.12/source/drivers/ata/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/… elixir.free-electrons.com/linux/v4.12/source/drivers/scsi/…

          – Tom Yan
          Aug 25 '17 at 1:43















          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
          Aug 25 '17 at 12:14





          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
          Aug 25 '17 at 12:14













          0














          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).






          share|improve this answer


























          • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

            – DominicM
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 13:28











          • @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
            Aug 25 '17 at 13:38
















          0














          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).






          share|improve this answer


























          • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

            – DominicM
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 13:28











          • @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
            Aug 25 '17 at 13:38














          0












          0








          0







          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).






          share|improve this answer















          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).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Aug 25 '17 at 13:40

























          answered Aug 25 '17 at 1:24









          Tom YanTom Yan

          1113




          1113













          • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

            – DominicM
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 13:28











          • @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
            Aug 25 '17 at 13:38



















          • fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

            – DominicM
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 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
            Aug 25 '17 at 13:28











          • @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
            Aug 25 '17 at 13:38

















          fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

          – DominicM
          Aug 25 '17 at 9:31





          fdisk from util-linux 2.28.2 so it couldn't have been the problem in any case.

          – DominicM
          Aug 25 '17 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
          Aug 25 '17 at 12:45





          @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
          Aug 25 '17 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
          Aug 25 '17 at 13:01





          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
          Aug 25 '17 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
          Aug 25 '17 at 13:28





          @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
          Aug 25 '17 at 13:28













          @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
          Aug 25 '17 at 13:38





          @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
          Aug 25 '17 at 13:38


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f388157%2fparted-not-properly-auto-aligning-sectors-for-usb-drive%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          CARDNET

          Boot-repair Failure: Unable to locate package grub-common:i386

          濃尾地震