[dm-crypt] simple ideas addressing ssd TRIM security concern

Sven Eschenberg sven at whgl.uni-frankfurt.de
Mon Apr 16 00:48:41 CEST 2012

The purpose of TRIMing is to get erase pages as soon as possible back into
the allocation pool. These pages can then be erased (as needed) to
increase  'write' performance and have enough allocateable free pages for
upcoming writes (which are actually read, modify, erase, write, ops, while
TRIMing helps in prefetching the very expensive erase op).

An erase block is a continuous block of sectors. As long as not all FS
blocks covering this erase block were trimmed, the advantage of trimming
is anihilated (for obvious reasons). As an example, assume a 64k erase
page size and 4k FS-blocks. Now erase a big file (i.e. 1GB), while only
trimming 1% of the covered space randomly. The probability that you'd TRIM
multiple sets of 16 continuous FS blocks (if we assume proper alignment)
when only trimming 1% of the 1GB file is next to zero. If the FS blocksize
is smaller and the erase page size bigger, it's even worse.

Sidenote: An erase page size of 512KB is not really uncommon for MLC NAND.

As Arno already said, all you can do is weigh out leakage versus performance.

On Sun, April 15, 2012 18:55, alban bernard wrote:
> --- On Sun, 4/15/12, Sven Eschenberg <sven at whgl.uni-frankfurt.de> wrote:
>> That would render TRIMing completely
>> useless anyway and you could as well
>> turn it off.
> Not really if there are enough TRIMed blocks before block writes occur.
> There lies the purpose of a "smart" layer that will be responsible of
> TRIMing blocks in a certain amount of the total space: a kind of TRIMed
> block buffer that smooths writing zeroes and spreads them among the device
> the "crypto" way.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list