Partitioning and SSD: GPT, alignment, TRIM, encryption

itektur · 2016-01-31 16:11:49

I want to move the system partition of my current Arch installation to an SSD. I use an old-school BIOS and GRUB and I want to move /boot and / to the SSD while keeping directories like /home and /var on my hard disk. The root directory should be encrypted (LUKS) and TRIM support should be enabled since there is not really sensitive data stored on the system partition anyway.

I read various articles in the wiki, forum posts and whatever I could find in the web about the things that are important for me. Some of the things mentioned there seem to be outdated, or at least I cannot tell whether they still apply. Because of that, I need to ask certain questions here again:

How does using a different partition table (msdos, GPT) affect the performance and/or alignment issues of an SSD? If GPT should be preferred, is it possible to boot from BIOS, and if so, where do I need to tweak which values (e.g. for keeping space left for GRUB but with everything still aligned)?
Using Gparted, do I need to align to MiB or to cylinders? In general, how can I tell afterwards whether a given partition is properly aligned or not?
How can I tell whether calling fstrim for an encrypted device will eventually reach the SSD and discard blocks properly?
Where do I find all the information I need to ensure that I use the right block/sector sizes to both maximize performance and minimize SSD wear?

I will try to answer the questions myself:

There is no performance gain whatsoever when using GPT. Therefore, msdos will work without any negative side effects.
Using an msdos partition table, I think I should align to MiB. After mounting a file system, a message like "Performance will be poor" will appear in the logs if things are not properly aligned for some reason. However, I know this only from hard disks so I don't know whether this will appear in case of an SSD as well. Does such a message also appear if I use an encryption layer inbetween? Does blockdev --getalignoff tell me what I want to know? Also, I don't know whether such a message will also appear if the alignment itself is correct but the sizes are different. For example, if the file system uses 4096 bytes per block but the SSD uses 512 bytes per sector (physically), writing a single file system block might affect 8 physical sectors instead of only one, even if the blocks and sectors are aligned. Even worse, if the SSD uses 4096 bytes per sector (physically) but the file system uses 512 bytes per block, writing 8 consecutive file system blocks might result in writing all 4096 bytes of a single SSD sector eight times instead of only once! Is this correct or do I miss something here?
I don't know yet.

This is an interesting question because different programs tell me different sizes:

# fdisk -l /dev/sdc
Disk /dev/sdc: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8f9d1781

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sdc1         2048    309247    307200   150M 83 Linux
/dev/sdc2       309248 234440703 234131456 111.7G 83 Linux

# blockdev --getbsz --getpbsz --getss --getalignoff /dev/sdc
4096
512
512
0

So, which values do I need to use where? fdisk says that both physical and logical sector size is 512 bytes, so where does the 4096 come from in blockdev's output?

As you can see, I already created partitions using an msdos partition table. /dev/sdc1 is where /boot should go to, and / should go to /dev/sdc2. Do all the values (especially "Start" and "End") look reasonable for what I want to do, or do I need to change something?

Head_on_a_Stick · 2016-01-31 19:09:06

I would recommend using a GUID partition table 'cos it newerer and betterer -- unlimited partitions, backup table at the end of the disk, full compatibility with UEFI, etc

If you use gdisk it will align the partitions automatically.

Don't use gparted, the GUI just confuses things IMO.

EDIT: typo

Last edited by Head_on_a_Stick (2016-01-31 19:09:33)

Rethil · 2016-01-31 20:17:22

1. There is no performance boost when using GPT instead of MBR.
2. I would suggest to use some other tools like fdisk or gdisk. From what I know SSD uses 4K blocks internally and firmware emulates 512 for compatibility with legacy systems.
3. No idea.
4. Maybe this will help you.

R00KIE · 2016-01-31 22:01:24

1 - Both fdisk and gdisk should align partitions properly.
2 - Use either fdisk or gdisk.
3 - If you are using ext4 it will complain if you do an fstrim, if you are using another filesystem it might not give you any warnings. When in doubt follow the wiki [1].
4 - At least fdisk will align things to 1MiB boundaries so it is more than enough, when in doubt use the larger value. Modern tools will also try to align things properly so it shouldn't be a problem.

The output of 'blockdev --getbsz --getpbsz --getss --getalignoff /dev/sdc' for me is:

You may want to see what smartctl and/or hdparm have to say about sector sizes to see if you can understand where the differences are coming from.

[1] https://wiki.archlinux.org/index.php/Dm … _.28SSD.29

Arch Linux

#1 2016-01-31 16:11:49

Partitioning and SSD: GPT, alignment, TRIM, encryption

#2 2016-01-31 19:09:06

Re: Partitioning and SSD: GPT, alignment, TRIM, encryption

#3 2016-01-31 20:17:22

Re: Partitioning and SSD: GPT, alignment, TRIM, encryption

#4 2016-01-31 22:01:24

Re: Partitioning and SSD: GPT, alignment, TRIM, encryption

Board footer