Поддержка TRIM через dm-crypt / device-mapper

Завтра получим новый ноутбук с SSD. Мне нужно знать о текущем состоянии dm-crypt и TRIM. Я видел несколько противоречивых сообщений, и большая часть активности вокруг этого вопроса, кажется, старше 1 года. Некоторые говорят, что TRIM-пропуск dm-crypt был включен в несколько последних версий ядра (для меня это не проблема, так как я использую Arch). Некоторые говорят, что поддержки до сих пор не существует. Могу ли я получить четкий ответ о состоянии поддержки TRIM dm-crypt? Git коммитов или рассылки объявлений, которые упоминают эту функцию, было бы идеально.

Ответ на этот вопрос имеет большой потенциал, чтобы повлиять на то, как я создаю диски для моего нового ноутбука. Надеюсь, кому-то будет полезно получить достойный, актуальный ответ.

Для записи, эта функциональность НЕ существовала, когда я впервые опубликовал этот вопрос. Я спросил в списке рассылки, и Милан Броз сообщил мне, что отмена передачи для целей dm-crypt до сих пор не реализована. Милан указал, что намерен реализовать это в какой-то момент, но не уточнил, когда.

Некоторое время копаясь в dm-crypt.c и связанных с ним файлах, оказалось, что добавить поддержку TRIM будет довольно тривиально. Я написал список с просьбой дать им общие рекомендации по выполнению этой задачи, прежде чем приступить к работе. На следующий день Милан представил патч, в котором реализована сквозная передача TRIM для dm-crypt, и он был встроен в linux-next. Он должен быть включен в ядро ​​Linux 3.1.

TRIM passthrough должен быть включен явно. Существуют потенциальные проблемы безопасности при использовании TRIM на устройстве dm-crypt'd, потому что TRIM отправляет информацию об использовании блока встроенному программному обеспечению на устройстве, которое затем отмечает недавно освобожденные области как пригодные для использования (в любом случае, как я понимаю). Это означает, что заинтересованная сторона может получить информацию о моделях использования диска. Например, постулировалось, что злоумышленник может почти точно узнать, какая файловая система использовалась на зашифрованном носителе, используя эти данные. Злоумышленник также может узнать больше полезной информации, например, что до недавнего времени у вас было сохранено много больших файлов (большие смежные блоки TRIM).

Пожалуйста, смотрите эти темы для справки:

http://www.redhat.com/archives/dm-devel/2011-June/msg00093.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00042.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00088.html

tl; dr: TRIM сквозная поддержка для целей dm-crypt будет существовать в Linux> = 3.1, но должна быть включена вручную через cryptsetup и / или dmsetup из-за утечки данных, которая может позволить профилирование на основе шаблонов использования диска.

Начиная с ядра 3.2.x, dm-crypt + brtfs считается безопасным. Смотрите ответ на мой вопрос от Криса Мейсона:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15554 и http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15564

Согласно этому посту ...

Мой вопрос: что происходит, если между файловой системой и реальным блочным устройством находится слой dm-crypt? Будет ли отделка пропущена или она будет отброшена?

Думаю, это будет пройдено. Я использую btrfs на SSD, который зашифрован с помощью LUKS / dmcrypt, и он прекрасно работает. Btrfs довольно долго использует ata trim.

Вам также могут понадобиться discardопции монтирования файловой системы.

ну есть эта тема

https://bbs.archlinux.org/viewtopic.php?id=114924

и этот инструмент

http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684

Я еще не использовал это, но я также заинтересован в этой проблеме.