SSD partition alignment -- Is the Wiki wrong or am I wrong?

Neverlasting · 2013-12-11 17:39:53

Hi,

I recently installed Arch Linux to an Apple computer that has an SSD (plus an HDD) in it. If I remember correctly, I used Apple's disk partitioning tool to make room for Arch Linux on the SSD beside the Mac OS partitions. Then I installed Arch and was very happy until I realized that my SSD's partitions might be not properly aligned.

The Wiki says, to check alignment, one should use this command:

blockdev --getalignoff /dev/<partition>

The Wiki claims, if this prints 0, everything's in order. In my case, it does print 0 for all partitions on my SDD (and HDD).

However, there seems to be another way to check if the partitions are aligned: using parted's command "align-check". My output (for your convenience also with the partition table using sectors and bytes as units, if it's of any help):

(parted) p                                                                
Model: ATA APPLE SSD SD0128 (scsi)
Disk /dev/sdb: 121GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
 1      20.5kB  210MB   210MB   fat32        EFI System Partition  boot
 2      210MB   21.5GB  21.3GB               Fusion
 3      21.5GB  21.7GB  134MB   hfs+         Booter
 4      21.7GB  121GB   99.5GB  ext4         Arch Linux SSD

(parted) align-check opt 1                                                
1 not aligned
(parted) align-check opt 2                                                
2 not aligned
(parted) align-check opt 3                                                
3 not aligned
(parted) align-check opt 4                                                
4 not aligned

(parted) unit s                                                           
(parted) p                                                                
Model: ATA APPLE SSD SD0128 (scsi)
Disk /dev/sdb: 236978176s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start      End         Size        File system  Name                  Flags
 1      40s        409639s     409600s     fat32        EFI System Partition  boot
 2      409640s    42075319s   41665680s                Fusion
 3      42075320s  42337463s   262144s     hfs+         Booter
 4      42337464s  236715991s  194378528s  ext4         Arch Linux SSD

(parted) unit B                                                           
(parted) p                                                                
Model: ATA APPLE SSD SD0128 (scsi)
Disk /dev/sdb: 121332826112B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start         End            Size          File system  Name                  Flags
 1      20480B        209735679B     209715200B    fat32        EFI System Partition  boot
 2      209735680B    21542563839B   21332828160B               Fusion
 3      21542563840B  21676781567B   134217728B    hfs+         Booter
 4      21676781568B  121198587903B  99521806336B  ext4         Arch Linux SSD

(parted) align-check min 1                                                
1 aligned
(parted) align-check min 2                                                
2 aligned
(parted) align-check min 3                                                
3 aligned
(parted) align-check min 4                                                
4 aligned

I don't really understand the difference between the "min" and "opt" options. Anyway, "opt" seems to be the default and it says the partitions are not aligned. Now what to believe? Are my partitions aligned or not?

If it's of any use, here's some additional info from /sys/block about my device:

$ cat /sys/block/sdb/queue/physical_block_size
4096
$ cat /sys/block/sdb/queue/logical_block_size
512
$ cat /sys/block/sdb/queue/minimum_io_size
4096
$ cat /sys/block/sdb/queue/optimal_io_size
0
$ cat /sys/block/sdb/alignment_offset           
0
$ cat /sys/block/sdb/sdb1/alignment_offset 
0
$ cat /sys/block/sdb/sdb2/alignment_offset
0
$ cat /sys/block/sdb/sdb3/alignment_offset
0
$ cat /sys/block/sdb/sdb4/alignment_offset
0

I'm really puzzled. Hope you can shed some light on it. Thanks!

Last edited by Neverlasting (2013-12-11 18:00:17)

Roken · 2013-12-11 18:13:49

I can't help with any answer, other than to say both blockdev and parted (each of opt and min) report my SSD partitions as properly aligned

Neverlasting · 2013-12-11 22:09:35

Okay, so I guess you have a different partition table. I did some more digging and found this post on a forum. Basically it says that what matters is that partitions are aligned to the "file allocation unit size", which apparently is 4096 bytes. And one can verify that in my partition table (see the post above) all the partitions start at a multiple of 4096, so this seems to be okay. However, they appear not to be aligned to the "NAND erase block size", which seems to be 512 kilobytes...? The poster claims that "it's not an issue", since the only thing that's important is being aligned to the file allocation unit size.

Is this true?

My knowledge of SSDs is, unfortunately, very basic. I'm glad if anyone can help out.

frostschutz · 2013-12-11 22:14:42

I didn't know about blockdev --getalignoff. I don't trust parted align-check either.

I align everything to MiB boundaries. That works for every drive I had thus far.

The parted output you posted is inconclusive regarding alignment... print it again with unit s and you'll know. I'd not consider your efi boot partition aligned, but that's the one that doesn't really matter either way.

EDIT: --getalignoff prints 0 for me for partitions that are clearly not aligned; it believes the 512 byte sector size too easily. so it's useless for practical purposes

Last edited by frostschutz (2013-12-11 22:17:22)

Neverlasting · 2013-12-11 22:34:59

frostschutz wrote:

I align everything to MiB boundaries. That works for every drive I had thus far.

Hmm, I guess you can't go wrong with that. Maybe I'll do that, too, if I indeed have to realign my partitions.

frostschutz wrote:

The parted output you posted is inconclusive regarding alignment... print it again with unit s and you'll know. I'd not consider your efi boot partition aligned, but that's the one that doesn't really matter either way.

I did quote the output with unit s, among other units. But yes, the EFI partition is clearly not aligned to 512 kiB. Neither are the other partitions, it seems. So I guess I really have to repartition if I care about longevity of my SSD?

Last edited by Neverlasting (2013-12-11 22:35:14)

cfr · 2013-12-12 01:16:43

How does gdisk show your partition table? (I'd trust gdisk more than parted but perhaps that's just me. gdisk is clearer and more accurate about many things e.g. it doesn't use misleading terms to refer to setting the type of the ESP as EFI etc.)

Neverlasting · 2013-12-12 18:34:53

cfr wrote:

How does gdisk show your partition table? (I'd trust gdisk more than parted but perhaps that's just me. gdisk is clearer and more accurate about many things e.g. it doesn't use misleading terms to refer to setting the type of the ESP as EFI etc.)

Thanks for the hint. By now I moved partition 4 (the one with my Arch system on it) using gparted on a live USB system such that it is now aligned. The other partitions are still not properly aligned (it seems), but since I'm not going to use them or write to them often anyway, I hope that's not much of a problem.

Here's the output of gdisk.

Command (? for help): p
Disk /dev/sdb: 236978176 sectors, 113.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 09012299-8403-4A78-A676-E5B1BA2A7DEC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 236978142
Partitions will be aligned on 8-sector boundaries
Total free space is 262957 sectors (128.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640        42075319   19.9 GiB    AF05  Fusion
   3        42075320        42337463   128.0 MiB   AB00  Booter
   4        42342400       236720127   92.7 GiB    AF00  Arch Linux SSD

Do you think it makes sense to align the other partitions as well? (Might be painful since gparted, understandably, does not seem to be able to handle the Fusion partition which is part of a logical volume group from Mac OS X.)

Last edited by Neverlasting (2013-12-12 18:40:24)

frostschutz · 2013-12-12 19:50:48

Neverlasting wrote:

I did quote the output with unit s, among other units

Oh sorry, must've missed the scroll bar then.

Well, it's only 4k aligned, dunno if that is sufficient or not.

cfr · 2013-12-13 03:17:25

Neverlasting wrote:

Partitions will be aligned on 8-sector boundaries

Yes. As the previous post indicated, this isn't usual. gdisk in my case aligns to 2048-sector boundaries (with the same sector size). I don't probably need it to be that large but I believe this is the safe default, especially for drives using newer technologies and larger sector sizes.

However, if this is a Mac and you partitioned using diskutil (or Disk Utility), I would certainly not mess with it without doing further research as that really should get it right. But I know very little about current Mac partitioning (except that diskutil is often recommended for partitioning prior to installing Linux).

Neverlasting · 2013-12-14 14:18:16

cfr wrote:

Yes. As the previous post indicated, this isn't usual. gdisk in my case aligns to 2048-sector boundaries (with the same sector size). I don't probably need it to be that large but I believe this is the safe default, especially for drives using newer technologies and larger sector sizes.
However, if this is a Mac and you partitioned using diskutil (or Disk Utility), I would certainly not mess with it without doing further research as that really should get it right. But I know very little about current Mac partitioning (except that diskutil is often recommended for partitioning prior to installing Linux).

Thanks. So in the output "... will be aligned on X-sector boundaries" you have X=2048, while I have X=8?

Please correct me if I'm mistaken: I suppose gdisk somehow computes this number using data provided by my drive. Let's assume that this number is correct. This value of X should then tell me where my partitions have to be located in order to be aligned. (In my case, they have to start at multiples of 8 sectors.) So might it just be that my SSD uses smaller physical blocks (consisting of 8 sectors = 4 KiB) than in your case? If this is so, then I probably wouldn't have anything to worry about, but having realigned my Arch Linux partition to start at a multiple of 1 MiB would probably do no harm.

I've got a lot of conclusions in this reasoning that I'm very unsure of, so please point out any errors in it.

WonderWoofy · 2013-12-14 16:33:04

The gptfisk tools will query the disk for information like block/sector size. But as far as I know, this is for informational purposes only.

The reason it starts at 2048 is because that is a point which is sufficiently able to ensure alignment on disks with 512b sectors, 4k sectors, as well as things like mdadm, lvm, etc.

I believe it then tries to simply ensure that partitions end and start such that they are also multiples of a sane chunk size. But I'm not sure if it tries to do 1M or multiples of 2048 sectors or what. This of course can be overridden by specifying an exact end point in the disk.

srs5694 · 2013-12-14 16:57:17

Neverlasting wrote:

Please correct me if I'm mistaken: I suppose gdisk somehow computes this number using data provided by my drive.

No. I'm gdisk's author, and at the time I wrote the alignment code, I couldn't get reliable data on logical vs. physical sector size or optimal alignment values out of any kernel I tried. (There were system calls that were supposed to provide such data, but they never worked for me.) Thus, I settled on a simpler method: gdisk sets 2048-sector alignment by default unless the program detects that the disk is smaller than a certain size (which has crept down over time) and existing partitions seem to be aligned to a smaller power-of-2 value (say, 8-sector alignment). This is a fairly conservative default alignment policy that works for most people. The negative effects of losing even close to 1MiB of disk space because of an unnecessary 2048-sector alignment are puny on modern disks, whereas the performance costs of misaligning partitions on an Advanced Format disk are huge. Thus, favoring what has become the industry standard of 2048-sector alignment makes sense.

That said, I've noticed that I'm getting more reliable alignment and physical-vs-logical sector size data of late, so I may revisit some of this. I'm likely to stick with a default alignment value of 2048, but use the kernel's claimed optimum alignment or physical-vs-logical size data to set a lower bound on the default alignment value.

Also, most of my own personal attention has been on spinning disks and Advanced Format, not on SSD technologies. Some of the system calls that are supposed to return alignment values are the same for both technologies, but as I don't currently own any SSDs, I've not been able to test with them.

cfr · 2013-12-15 00:16:26

WonderWoofy wrote:

But I'm not sure if it tries to do 1M or multiples of 2048 sectors or what.

Which are equivalent if the sector size is 512 bytes...

WonderWoofy · 2013-12-15 00:28:32

@cfr, yes it would be, I was thinking about the possibility of it reacting to 4k disks with the 2048 sectors. But now that I think about it I remember reading that most advanced format disks actually report 512b sectors for compatibility reasons.

In any case, the real authority has answered the question, so I think my comment can be pretty much disregarded.

R00KIE · 2013-12-15 15:17:20

WonderWoofy wrote:

@cfr, yes it would be, I was thinking about the possibility of it reacting to 4k disks with the 2048 sectors. But now that I think about it I remember reading that most advanced format disks actually report 512b sectors for compatibility reasons.

Some do seem to report 512B logical / 4096B physical, but that also depends on the interface type you're using, you will get different values if you connect the disk via a translation chip or directly.

srs5694 · 2013-12-15 16:50:18

R00KIE wrote:

Some do seem to report 512B logical / 4096B physical, but that also depends on the interface type you're using, you will get different values if you connect the disk via a translation chip or directly.

To the best of my knowledge, all disks with 4096-byte physical sectors report logical sector sizes of 512 bytes on their native interfaces (SATA, generally). Some USB enclosures, though, translate in the other direction, and tell the computer that the disk has 4096-byte sectors. This has been causing problems of late when people try partitioning a disk "raw" and then transferring it to a USB enclosure or vice-versa.

Also, it's entirely possible that manufacturers will begin selling disks that report 4096-byte logical sectors, or even that such disks are available already and I don't know about them.

R00KIE · 2013-12-15 21:04:57

I guess I should have been more specific, like you say, disks usually report a logical size of 512B for compatibility even though the physical size is larger. From personal experience and from what I remember, when the disks are connected via their native interface they manage to report to correct physical sector size.

What you mention about some USB enclosures doing "funny" stuff doesn't surprise me, although the behavior you mention is news to me. What I've seen before is the disk size being reported as slightly smaller (3.5'' external disk from one well known brand) and the controller hanging if smart parameters are queried while there is some write activity (2.5'' external disk from another well known brand). As you can imagine I wasn't amused by this tricks.

I suppose SSDs are not better in this regard, personally I don't have experience with SSDs but every once in a while I see people asking the same questions about alignment over and over again. I suppose in the end you are the one getting blamed for something that can't be done right because disks/controllers lie.

Arch Linux

#1 2013-12-11 17:39:53

SSD partition alignment -- Is the Wiki wrong or am I wrong?

#2 2013-12-11 18:13:49

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#3 2013-12-11 22:09:35

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#4 2013-12-11 22:14:42

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#5 2013-12-11 22:34:59

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#6 2013-12-12 01:16:43

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#7 2013-12-12 18:34:53

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#8 2013-12-12 19:50:48

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#9 2013-12-13 03:17:25

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#10 2013-12-14 14:18:16

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#11 2013-12-14 16:33:04

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#12 2013-12-14 16:57:17

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#13 2013-12-15 00:16:26

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#14 2013-12-15 00:28:32

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#15 2013-12-15 15:17:20

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#16 2013-12-15 16:50:18

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

#17 2013-12-15 21:04:57

Re: SSD partition alignment -- Is the Wiki wrong or am I wrong?

Board footer