1

SUMMARY

I have a Dell Inspiron 17-5767 laptop with a 1TB internal disk I've allowed the originally shipped Windows 10 to continue to have and dominate all to itself (it's my gaming OS). Additionally I have two external drives from which I do and will boot my current and future Linux OS. My current setup is as follows:

  1. USB 3.0 Port #0: Seagate Expansion+ 931.5 GiB (1000204885504 bytes) External HDD recognized as /dev/sdb
    • currently housing one full-size, empty ext4 partition, but have been struggling to replace this with an optimal aligned partitioning scheme of 12 partitions (the point of struggle being with the alignment)
  2. USB 3.0 Port #1: 238.5 GiB (256060514304 bytes) Samsung SSD 840 Pro recognized as /dev/sdc
    • was partitioned using the Fedora LiveCD's installer (with the "custom" option), and houses both my Fedora LXDE and Lubuntu linux distros within a single LVM containing a shared swap space, shared user space, separate roots, and separate external boot partitions (by external here, I just mean not in the LVM but in their own separate primary partitions elsewhere on the same disk)
    • This drive has both a physical and logical block size of 512, and is optimally aligned, according to parted's 'align-check opt x' utility, and fdisk is happy with the alignment too (no alignment complaints from any utility)
  3. UEFI BIOS attempts to boot from USB before internal so I get grub popping up with all my available options

GOAL

I'm trying to replicate something like what I have going on with /dev/sdc on /dev/sdb drive, but with 5 linux distros. That aspect of my project I have covered, as I'm an experienced multi-booter. But the other part of my goal is for my partitioning on /dev/sdb to be optimally alligned just like is the case with /dev/sdc, and this is where I'm running into trouble.

ENVIRONMENT

I'm currently working from within my relatively fresh and upgraded install of Fedora LXDE, and the results I'm getting are fully repeatable in my also relatively fresh and upgraded install of Lubuntu as well.

REPORTED DISK PARAMETERS

[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size 
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size 
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset 
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 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: 9428D9DB-746C-40CA-B189-060F92A10E3C

Device     Start        End    Sectors   Size Type
/dev/sdb1  65535 1953467279 1953401745 931.5G Linux filesystem

Partition 1 does not start on physical sector boundary.
[root@frank ~]#

PROBLEM

So it appears, based on the reporting of the physical block size, that the disk is 4k (advanced format) instead of 512b like the other drive, even though for backward compatibility purposes it is using a logical sector size of 512b. I can tell that GNU parted utility is assuming a block size of 512, because when it calculates the optimal IO interval

(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval

it gets a value of 65535, which is where it will automatically start the first partition, and the only way the align-check sub-utility will pass a partition alignment as optimal is if it starts on a multiple of 65535. The only way parted's result makes sense is if you consider that it is treating the physical_io_size as 512 instead of 4096

(33553920 + 0) / 512 = 65535.

However, parted understandably cannot use the 4096 block size, because then the equation would work out to

(33553920 + 0) / 4096 = 8191.875.

That answer would satisfy a highschool algebra teacher, but obviously makes no sense as a sector interval for which one would expect a discrete value (i.e. an integer!). In any case, because I want to make 12 partitions, some of which are as small as 256MiB in size, that's not possible to do in GNU Parted using percentages, and long story short I was only able to satisfy align-checks for optimal alignment sticking with 'unit s' and doing the modular arithmetic myself to ensure my partitions started at 65535s intervals, the way parted wanted me to. Based on my research, I didn't think it was as important to ensure my partitions also ended at those intervals, and hence I was left with gaps (obviously no larger than 65535) between most of my partitions.

Once again, parted thought my result was optimally aligned, treating the physical block size as 512 instead of 4096. But then after quitting parted and running 'fdisk -l /dev/sdb' I got contained within the output the following:

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.

So, what parted likes, fdisk doesn't. So then I tried to use gParted to redo my partitioning scheme, letting it use 1 MiB as the unit size, and it started the first partition at 2048s, like you'd see on my other disk (/dev/sdc). fdisk was then happy and stopped complaining about sector alignment, but then GNU parted failed the align-check tests for optimal mode, although it would pass for the minimum mode.

I did find, however, that in both cases, mkswap (which I used to create a swap volume within the LVM I placed on /dev/sdb11) gave me the following warning:

[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned

So mkswap finds my swap volume to be misaligned whether parted thinks the disk is optimal aligned or minimum aligned, and mkswap also finds my swap volume misaligned whether fdisk is happy about alignment or not.

THEORIES

All this leaves me with the impression that I may have to ignore warnings from at least one disk reporting or partitioning utility, but I'm not confident which one. It's also possible that all reporting is unreliable to begin with as the USB-compatible enclosure containing the HDD might be misreporting at least one of the sector parameters. For instance, maybe it's not actually an AF drive? Or maybe it's optimal IO size is being misreported. Or maybe both? And, trust me, I've also considered the possibility that this is a PEBKAC case, as I might just be misunderstanding something about how to align partitions on a 4k drive. I'm not sure.

Whatever is going on, I will be happy moving forward with my actual Linux installations once I believe my partitions are optimal aligned and mkswap, or at least the utilities I should really be trusting the most, stop complaining about alignment.

HELP

Please help me understand why I can't seem to get parted and other disk utilities to agree on anything more than minimum alignment (achieved only when partitioning with either gParted or gdisk), and please advise me on whether I should really be worrying too much about the advantages of optimal alignment over minimum alignment in my case, as I won't waste further time if there is too insignificant a difference in performance or disk health. Otherwise, I would like to be able to take full advantage of my disk's advanced format benefits.

10
  • On an AF disk with a 4096 byte physical sector size, partitions should start aligned to this size. I.e. the starting 512-byte sector number should be a multiple of eight. It's as simple as that. Commented Feb 2, 2018 at 18:00
  • Right, and as I pointed out when a multiple of 8 gets used, like a starting point of 2048s (like what I got with gParted), then the parted utility sees the disk as not optimal aligned, but only minimum aligned, and mkswap complains that my swap volume within the LVM is misaligned whether I stick with the 2048s or conform to parted's bizarre demand for a 65535s interval for optimal alignment. Just look at the sector parameters that the system drew. How can I even trust that those parameters are being correctly reported in the first place?
    – gluonman
    Commented Feb 2, 2018 at 18:20
  • My internal drive is an identically sized AF drive. The only difference is that it doesn't have a weird optimal IO size that warrants a sector interval outside the discrete space. It's optimal IO size is the same as it's minimum IO size of 4096, and it starts at 2048s, and parted thinks its partitions are optimal aligned. Hence, I'm wondering if the only reason my utilities are complaining about misalignments, and that parted wants me to use 65535, is because the optimal IO size is a wrong number. I think that's my best hypothesis atm. But I just want to be sure I'm actually optimized.
    – gluonman
    Commented Feb 2, 2018 at 18:25
  • 1
    The "optimal IO size" is just a hint of some sort, and 65535 is definitely not optimal to use as the number of 512 byte sectors to start a partition on. The GParted manual says: "Use MiB alignment for modern operating systems." Commented Feb 2, 2018 at 18:38
  • Okay. It's becoming established in my head that parted is just plain wrong in what it thinks is optimal (on both my Fedora and my Lubuntu), because the optimal IO size "hint" coming from this particular drive is throwing it off. Would you agree? I mean, I knew the numbers were weird, but I've trusted parted for years, and this is honestly the first time I've ever seen it throw alignment issues at me. So I should probably just go ahead and stick with 2048s intervals and ignore parted's complaints (and mkswap's, for that matter), right?
    – gluonman
    Commented Feb 2, 2018 at 18:45

1 Answer 1

1

In case you are still confused by the bizarre number 65535s. I am also confused by this question recently. I searched for an answer and came across this one: http://gparted-forum.surf4.info/viewtopic.php?id=17839

Briefly, the optimal_io_size might be invalid when the HD is attached to a PC with a usb-sata adapter.

The solution is just to ignore this number and stick to the 1MiB boundary suggestion.

1
  • Oh thank you very much!!!! I've been Duckducking this for ages
    – HypeWolf
    Commented Oct 9, 2019 at 23:29

You must log in to answer this question.

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