SSD, TRIM, LVM + LUKS

Насколько я понимаю, при работающем TRIM последняя колонка должна быть ненулевой.

Почему?

Почему?

Так в archwiki было написано. Не то, чтобы я им слепо верил, но в документации lsblk мало что написано по этому поводу.

Плюс, вывод по томам lvm и sda1 должен отличаться, т.к. в случае с sda1 используется ext2, которая не поддерживает discard.

Я бы сделал маленький тестовый раздел, создал, удалил файл и посмотрел раздел hex-редактором. Если я правильно понял, что такое trim, то на шифрованном разделе должны образоваться нули.

Спасибо. Как выяснилось, trim не работает - файл остался после отмонтирования.

А какой смысл использовть TRIM с шифрованным разделом? Если он сработает и при чтении данных в них будут нули (или FFы), то у dm-crypt может при расшифровке в другом месте (рядом) получиться мусор.

Ну и теоретически от этого страдает безопасность, так как будет ясно где есть данные, а где их нету.

fstrim завершается с ошибкой?

Плюс, вывод по томам lvm и sda1 должен отличаться, т.к. в случае с sda1 используется ext2, которая не поддерживает discard.

В ядре давно нет ext2, это ext4.

у dm-crypt может при расшифровке в другом месте (рядом) получиться мусор.

Нет, не может. Там ведется учет в каких секторах есть данные. Единственной проблемой может быть то, что «злоумышленнику» будет проще отличить зашифрованные данные от мусора, но в данном случае это не так важно.

> sudo fstrim -v /mnt/test           
/mnt/test: 237.9 MiB (249463808 bytes) trimmed

Но если открыть раздел в hexedit, данные из удаленного файла там всё равно присутствуют.

Хм... Тогда ок.

https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledan...

hdparm не работает с luks и lvm.

А кто их знает эти проприетарные контроллеры, как у них trim работает.

Но если открыть раздел в hexedit, данные из удаленного файла там всё равно присутствуют.

Они, похоже, и не обязаны отсутствовать. Как я понимаю, нулевое значение DISC-ZERO означает, что ячейки не перезаписываются '\0', но это никак принципиально не влияет на сборку мусора и write amplification.

http://gotf.point.im/tuaqy Если бы у меня TRIM не работал на самом деле, скорость записи, учитывая срок службы и количество записанного, давно упала бы ниже плинтуса, а не оставалась на уровне «только что из магазина» (а ещё у меня SandForce, лол).

Проиграл с этого http://i.point.im/m/g/gotf/ef/df/4893/08.-The-Decision-Maker-on-High-00-18-56...