SSD dm-crypt partition alignment

[Peter Smith]

Hello

I don't know if this is the correct list for this question, but so far
i do not have any better ideas.

I have installed an Intel X25-M SSD in my work laptop. I want to
encrypt this SSD and install Ubuntu 10.04 on it. LVM is not needed so
this will not be configured.

The articles on SSD i have read, explains that it is very important to
align the partitions correctly. Therefore i run fdisk like this:

fdisk -H 32 -S 32 /dev/sda

Then i have created three partitions boot, swap and root. Could i just
go on and continue to configure encryption like explained in this
article:

http://www.howtoforge.com/encrypting-the-system-manually-upon-installation-ubuntu8.04

And then everything will be aligned as it should? or does dm-crypt
need to be aligned somehow?

The Linux kernel used under installation is 2.6.32-21 and the
cryptsetup version is 1.1.0-rc2

Thanks for any suggestions

Peter

[Christoph Anton Mitterer]

Hi.


Unfortunately this is still rather black magic to me,.. especially when
one combines LVM/MD/partitons and perhaps even the striping options in
ext-filesystems.

But AFAIK, if you just want to use _LUKS_ (guess this does not work with
plain dm-crypt devices) on partitions, and if you use a recent enough
kernel (IIRC it was 2.6.34) and recent enough cryptsetup (IIRC 1.1.3)
then the alignment should happen automatically.

The payload offset in the LUKS header is simply set accordingly.

So AFAIK you shouldn't need to use "-H 32 -S 32"...


Any better experts,... please correct me if I'm wrong.


Cheers,
Chris.

[Peter Smith]

Post by Christoph Anton Mitterer
Hi.
Unfortunately this is still rather black magic to me,.. especially when
one combines LVM/MD/partitons and perhaps even the striping options in
ext-filesystems.
But AFAIK, if you just want to use _LUKS_ (guess this does not work with
plain dm-crypt devices) on partitions, and if you use a recent enough
kernel (IIRC it was 2.6.34) and recent enough cryptsetup (IIRC 1.1.3)
then the alignment should happen automatically.
The payload offset in the LUKS header is simply set accordingly.
So AFAIK you shouldn't need to use "-H 32 -S 32"...
Any better experts,... please correct me if I'm wrong.
Cheers,
Chris.

Hi

I agree with you on that. I have spent weeks investigating this, but
without finding any clear answers.

So far i am pretty clear on that i need to align the partitions to EBS
(erase block size). The EBS on Intel X25-M SSD is thought to be 512
KiB. By running fdisk with the parameters -H 32 -S 32 the partitions i
create will automatically be 512 KiB aligned. Everything would be fine
now, if i did not need to encrypt the drive, but because this is a
laptop used for work it is a demand.

We are using the newest Ubuntu LTS therefore cryptsetup and the Linux
kernel are not supporting automatic alignment. If i try to configure
LUKS without LVM through partman with everything default and then dump
the LUKS header, the "Payload offset" is configured to 2056, but i do
not know if this is fine or not?


Peter

[Christoph Anton Mitterer]

Post by Peter Smith
I agree with you on that. I have spent weeks investigating this, but
without finding any clear answers.
So far i am pretty clear on that i need to align the partitions to EBS
(erase block size). The EBS on Intel X25-M SSD is thought to be 512
KiB. By running fdisk with the parameters -H 32 -S 32 the partitions i
create will automatically be 512 KiB aligned. Everything would be fine
now, if i did not need to encrypt the drive, but because this is a
laptop used for work it is a demand.
We are using the newest Ubuntu LTS therefore cryptsetup and the Linux
kernel are not supporting automatic alignment. If i try to configure
LUKS without LVM through partman with everything default and then dump
the LUKS header, the "Payload offset" is configured to 2056, but i do
not know if this is fine or not?

Uhm... have not heard about that before ^^ (but again, I'm not an expert
in this alignment thingy).
I thought there would be only one block size the device is using (well
at most there might be an physical block size, and a logical one which
is "published", as some WD harddisks do (IIRC)).

Nevertheless,... with an SSD "erasing" only makes sense via TRIM, and my
most recent knowledge of the status of that was, that neither dm (and
therefore also LVM2), nor dm-crypt support it (yet).

And even if they would, dm-crypt would (hopefully) decide to block TRIM
per default, as it has some effect on security.


Cheers,
Chris.

[Bryan Kadzban]

Post by Christoph Anton Mitterer
Nevertheless,... with an SSD "erasing" only makes sense via TRIM,

Not really.

An SSD has to erase a whole erase-block (thought to be 512kB on the
Intel drives) whenever it can't satisfy a write from a currently-erased
device block (512 bytes or 4k or whatever). This is how flash works:
you have to erase before writing anything (unless the bits are all zero
already), and the smallest erase unit is >1 block. So other blocks from
the target erase-block must be copied to some other physical location,
or they'd be lost.

This has nothing to do with intentional discarding of data from the FS
layer via TRIM. (TRIM does help the SSD decide what other erase-groups
it can possibly use when it has to overwrite. But AIUI, that's all.
Note also that AFAIK the device doesn't have to actually *do* an erase
on TRIM, though I could be wrong on that. That might be an interesting
performance-versus-security tradeoff experiment, actually...)

If you can force your upper-level data transformations (device mapper,
possible raid, dm-crypt, filesystem, user programs running on the FS) to
happen in units of the erase block size, you can make write performance
a lot more predictable. Mind you, I don't know if it's possible to do
that, especially at the FS layer and above.

[Milan Broz]

Seems some confusion here, in short:

Data alignment:

- default cryptsetup <= 1.1.3 (LUKS data offset) alignment is 4k

- cryptsetup 1.1.3 understand topology info provided by kernel,
if storage (SSD) announces proper values, it is properly aligned
(kernel with topology ioctl support required)

- devel version (next cryptsetup, change in svn already) will use default alignment
to 1MiB (if 1 MiB is multiple of topology alignment, it remains 1MiB; otherwise
it is aligned according to topology info - useful for nonstandard RAID devices)

Aligning to 1MiB is now trend in storage technology and it is safe default
for most of these configs (I'll describe reasons in release notes).

If you want align LUKS even in old version or use explicit value
add to luksFormat --align-payload=2048
(in 512B sectors - here aligns to 1MiB boundary)

(in most cases it cause encrypted data offset to start on sector 4096)

All basic storage tools should now align to optimal values by default
(like fdisk/lvm2/cryptsetup/mdadm etc) - in recent versions.
So the whole storage stack should not suffer from possible misalignment.


TRIM:
(nothing to do with alignment above, this is also kernel-only thing)

- device-mapper in 2.6.36 have support for TRIM/discard except dm-crypt target.

dm-crypt ignores it, later we probably add some optional support,
but default will be always ignore trim/discard for security reasons.

Milan

[Christoph Anton Mitterer]

Post by Milan Broz
- cryptsetup 1.1.3 understand topology info provided by kernel,
if storage (SSD) announces proper values, it is properly aligned
(kernel with topology ioctl support required)

That was with > 2.6.34, right?

Post by Milan Broz
- devel version (next cryptsetup, change in svn already) will use default alignment
to 1MiB (if 1 MiB is multiple of topology alignment, it remains 1MiB; otherwise
it is aligned according to topology info - useful for nonstandard RAID devices)

btw: Is there a rough expectation on when you'll release the next version?

Post by Milan Broz
Aligning to 1MiB is now trend in storage technology and it is safe default
for most of these configs (I'll describe reasons in release notes).

You've also did that for lvm, right?

Post by Milan Broz
All basic storage tools should now align to optimal values by default
(like fdisk/lvm2/cryptsetup/mdadm etc) - in recent versions.
So the whole storage stack should not suffer from possible misalignment.

Do you perhaps know, about the status of cfdisk and gpart?
I personally use fdisk, but those two are also commonly used,... and if
we put that in the FAQ perhaps, it might be worth to add which tools are
known to support it.


Thanks,
Chris.

[Christoph Anton Mitterer]

Post by Bryan Kadzban
Not really.
An SSD has to erase a whole erase-block (thought to be 512kB on the
Intel drives) whenever it can't satisfy a write from a currently-erased
you have to erase before writing anything (unless the bits are all zero
already), and the smallest erase unit is >1 block.

Of course...

Post by Bryan Kadzban
So other blocks from
the target erase-block must be copied to some other physical location,
or they'd be lost.

But that whole issue is already solved when you're aligned to the
"write" blocks, isn't it?

The kernel doesn't know about, erase-first-then-write,... it's the
internal logic of the SSD which does this.

So from the software point of view, I thought, one has only writing
(with the exception of TRIM - but as you've said, those two have nothing
to do with each other),... and if you're aligned to the blocks, you're
fine.

Cheers,
Chris.

[Peter Smith]

I have been experimenting further with cryptsetup, and trying to learn
the concepts. So far i have learned that it is much more beneficial to
use LVM and dm-crypt combined. I have decided to use Serpent as
encryption alogrithm, and this results in Payload offset at 3072
sectors or 1536KiB when the argument --align-payload=1024 is passed to
cryptsetup, this is correct according to another post on this list. I
do not fully understand this part but i try to visualize that one LUKS
"unit" is now 1536KiB "wide" or 3 physical 512KiB erase blocks.
Partitions, LVM and everything else is aligned directly to 512KiB or 1
physical erase block. It is not possible to reduce one LUKS "unit" in
size because of keyslot space etc.

Is my storage stack still aligned even that one LUKS "unit" is 3
physical erase blocks wide, or should one LUKS "unit" be exactly
512KiB "wide" (which is not possible) before my storage stack is
aligned?

I am not sure that my understanding of the concepts is correct, so i
hope that someone can clarify this.

Thanks for any suggestions.