[dm-crypt] SSD dm-crypt partition alignment
cryptsetup at kdzbn.homelinux.net
Wed Aug 25 17:54:17 CEST 2010
Christoph Anton Mitterer wrote:
> Nevertheless,... with an SSD "erasing" only makes sense via TRIM,
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.
More information about the dm-crypt