самостоятельно убедиться, что TRIM действительно работает на SSD

У меня есть LUKSраздел, /dev/sda1который я luksOpen с --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

Затем я монтирую ext4файловую систему с discardопцией:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

Затем я обрежу свободное место на смонтированном разделе:

fstrim -v /

с df, я вижу, /имеет 80% свободного места. Это означает, что /dev/sda180% диска являются двоичными нулями.

Если я клонирую изображение с cat

cat /dev/sda1 > sda1.img

и сжать изображение xz, я ожидаю, что все нули на диске будут сжаты. Поскольку 20% данных на диске зашифрованы, они должны выглядеть случайными и быть несжимаемыми. Следовательно, xz-сжатое изображение должно быть приблизительно. 20% от необработанного размера.

Однако полученное xz-сжатое изображение имеет примерно такой же размер, что и необработанный оригинал.

Правильно ли мои рассуждения?

Почему моя теория не воплощается в практику?

Ваша логика не неверна. Но он действителен только при соблюдении некоторых условий.

Команда TRIM , как указано в наборе команд ATA , может или не может обнулять секторы, против которых она выдана.
На самом деле, стандарт фокусируется на том, какие данные должны быть возвращены после того, как TRIM был выпущен ¹ :

Следующие поведения определены этим стандартом для секторов, которые устройство урезает (см. 7.5.3.3):

а) недетерминированные - данные в ответ на чтение из урезанного сектора могут изменяться для каждого чтения, пока сектор не будет записан хостом;
b) Детерминированное чтение после обрезки (DRAT) - данные, возвращаемые в ответ на чтение обрезанного сектора, не изменяются, но могут отличаться от данных, которые были ранее возвращены; и
c) чтение нулей после обрезки (RZAT) - данные, возвращаемые в ответ на чтение обрезанного сектора, равны нулю.

[...] Как для DRAT, так и для недетерминированных запоминающих устройств данные возвращались в ответ на команду чтения в LBA, которая была успешно обрезана:

а) могут быть ранее возвращенные данные для указанного LBA;
б) может быть шаблоном, сгенерированным запоминающим устройством; и
c) не являются данными, ранее записанными хостом в другой LBA.

Таким образом, что ваше устройство возвращает после fstrim зависит от функций, которые оно реализует. Если он не поддерживает RZAT, предположение о том, что данные, считанные с обрезанного устройства, будут иметь только нули, не выполняется.

Вы можете использовать hdparmдля проверки этого:

sudo hdparm -I /dev/sdX | grep -i trim

Я провел несколько тестов, используя два SSD, sdaи sdb. Один и тот же производитель, разные модели, с разным соответствием ATA:

$ sudo hdparm -i /dev/sdb
 ...
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
 ...

$ sudo hdparm -i /dev/sda
 ...
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
 ...

Два SSD имеют разную поддержку TRIM:

$ sudo hdparm -I /dev/sda | grep -i trim
           *    Data Set Management TRIM supported (limit 1 block)

$ sudo hdparm -I /dev/sdb | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Я могу подтвердить, что после выдачи fstrim диск, поддерживающий «детерминированные нули чтения после TRIM» (RZAT), фактически обнажил соответствующий раздел почти полностью. И наоборот, другой диск, кажется, обнулел (или иным образом заменен каким-либо сильно сжимаемым рисунком) только незначительную часть освобожденного пространства.

¹ _{Онлайн источник: INCITS 529: Информационные технологии - Набор команд ATA / ATAPI - 4 (ACS-4)}

Примечание по тестированию:

Как указывает frostschutz в комментариях, чтение после fstrimможет возвращать данные из кэша операционной системы, а не из урезанного устройства. Это, например, то, что произошло в этой кастрации .
(Я бы также указал на этот ответ на тот же вопрос для альтернативного метода тестирования TRIM).

Между fstrimи последующим чтением вам может понадобиться удалить кеш, например, с помощью:

echo 3 | sudo tee /proc/sys/vm/drop_caches

В зависимости от размера раздела, с которым вы играете, может не хватить сброса кэша, чтобы ваши тесты не сработали.

Примечание по вашей настройке:

Опция discardмонтирования включает непрерывную TRIM, то есть в любое время файлы удаляются. Это не требуется fstrim. Действительно, TRIM по требованию и непрерывный TRIM - это два разных способа управления операциями TRIM. Для получения дополнительной информации я бы указал на твердотельный накопитель на Arch Linux Wiki, в котором подробно рассматривается этот вопрос.

Имеет ли SSD встроенный аппаратный уровень шифрования? Если он есть, блоки TRIMmed могут иметь все нули (или, возможно, все единицы) на уровне аппаратного обеспечения, но, поскольку компьютер видит их через уровень шифрования, они будут отображаться как псевдослучайная тарабарщина после прохождения всех Обнуление сырого блока в процессе дешифрования.

Такой уровень аппаратного шифрования будет иметь некоторые преимущества:

• Это позволило бы очень быстро стереть функции безопасности: достаточно, чтобы диск уничтожил исходный ключ, использованный на аппаратном уровне шифрования, и заменил его новым, и все данные будут мгновенно восстановимы для большинства практических целей.
• Поскольку все данные, попадающие на уровень аппаратного обеспечения, будут зашифрованы, будет гарантированно выглядеть псевдослучайно и, следовательно, быть в значительной степени однородным. Это может помочь избежать горячих / холодных пятен и значительно упростить оценку износа.

Сброс не совпадает с нулем.

Если вы хотите обнулить с помощью cryptsetup, вы можете уменьшить fs, затем блок crypt и затем использовать неиспользуемое пространство тома.

Если вы хотите знать, работал ли триммер, выполнение теста скорости должно быть показателем после интенсивного использования.

https://linux.die.net/man/8/fstrim https://en.m.wikipedia.org/wiki/Trim_(computing)

df Сообщение о свободном пространстве не означает обнуление пространства.

trimсообщает устройству хранения, что блоки не используются. Я не думаю, что это обнуляет их.