LUKS+LVM+TRIM (Samsung 860 Evo)

В lvm.conf ещё надо включить:

devices {
  issue_discards=1
}

Как я понял, LVM по умолчанию пробрасывает команду TRIM, а опция issue_discards=1 действует только в случае удаления логических томов. Т.е. мне сейчас это не нужно.

Никогда не использовал LUKS. По поводу discard или fstrim по расписанию - IMHO, лучше по расписанию, чтобы при каждом удалении не запускать очистку.

Что говорит lsblk -D

Если не собираетесь манипулироват LVM — не надо.

LVM чисто на всякий случай сделал на будущее.

Так, а щас fstrim работает?

For non-root filesystems, configure /etc/crypttab to include discard in the list of options for encrypted block devices located on an SSD

Здесь нет разницы между root и non-root.

У меня только /, но добавление опции discard в /etc/crypttab позволяет (после перезагрузки) выполнить fstrim.

Тогда в чём проблема?

Почему fstrim ругается на отсутствие discard?

Потому что ты его не включил.

Что лучше, полноценно включить discard для / или делать fstrim по расписанию?

Зависит от характеристик диска и профиля нагрузки.

А вообще, у меня такое ощущение, что ты путаешь (смешиваешь) опцию discard в crypttab и опцию discard при монтировании ФС (в fstab).

Первая нужна в любом случае. Вторая — заменяется fstrim'ом по расписанию.

А вообще, у меня такое ощущение, что ты путаешь (смешиваешь) опцию discard в crypttab и опцию discard при монтировании ФС (в fstab).

Да, я путаю, потому прошу растолковать последовательно разницу и оптимальный алгоритм действий для меня. Очевидно, что есть люди с похожей конфигурацией.

Почему fstrim ругается на отсутствие discard?

Потому что ты его не включил.

У меня сложилось представление (возможно, ложное), что discard отвечает за автоматический trim сразу после удаление файлов. Если включен discard, то fstrim тогда уже не имеет смысла. Но, видимо, я ошибаюсь. Прошу разъяснить.

Что лучше, полноценно включить discard для / или делать fstrim по расписанию?

Зависит от характеристик диска и профиля нагрузки.

Использование на ноутбуке: браузер, код, немного компиляции (иногда много, но редко).

Заодно, пользуясь случаем, спрошу: стоит ли с учетом использования SSD изменить I/O scheduler на noop?

Только при добавлении опции discard в /etc/crypttab.

Да, я путаю, потому прошу растолковать последовательно разницу и оптимальный алгоритм действий для меня.

1. Опция discard в crypttab влияет на device-mapper. Она включает отображение (проброс) discard-запросов к расшифрованному блочному устройству в discard-запросы к настоящему блочному устройству.
2. Опция discard при монтировании ФС влияет на драйвер ФС. Она приводит к тому, что при каждой операции логического освобождения места на томе драйвер ФС отправляет соответствующий discard-запрос к блочному устройству, с которого ФС смонтирована.
3. Команда fstrim также влияет на драйвер ФС. Она заставляет драйвер ФС единовременно отправить discard-запросы для всего логически свободного места на томе.

Отсюда очевидно, что выбирать можно между (2) и (3), но вне зависимости от этого выбора нужно сделать (1), иначе discard-запросы, отправленные драйвером ФС к виртуальному расшифрованному блочному устройству, до настоящего диска просто не дойдут.

Этого достаточно. После этого вышерасположенные уровни (lvm, fs) начинают видеть воможность фичи дискард на нижерсположенном уровне, и использовать её при необходимости. Далее ты настраиваешь issue_discards в lvm (специфичная на самом деле вещь, точно затрудняюсь описать), и способы дискард для фс: это или перманентный дискард (который опцией монтирования указывается), либо/и использование fstrim. Примерно так

Большое спасибо за разъяснения, теперь стало понятно!

Теперь вопрос в выборе между (2) и (3) и как правильно включить (2)?

Спасибо! Что скажете на счет вопроса в предыдущем комментарии?

я лично сделал `systemctl enable fstrim.timer` и не включал опцию монтирования, и не парюсь. У меня xfs и ext4 на двух ssd. так же, с luks+lvm.

Теперь вопрос в выборе между (2) и (3)

Если твой диск поддерживает queued TRIM и он не забанен ядром Linux — делай и (2), и (3).

Если нет, и суммарный объём записей на диск за период между двумя запусками (3) меньше объёма свободного места на этом диске — делай только (3).

Если нет, но вышеописанное условие не выполняется — то либо делай только (3) и уменьшай длину периода между запусками (3), либо делай и (2), и (3), но ожидай умеренной потери производительности.

`systemctl enable fstrim.timer`

Это канонический вариант. Шляпа велит так делать уже много лет.

Если нет, и суммарный объём записей на диск за период между двумя запусками (3) меньше объёма свободного места на этом диске — делай только (3).

sudo fstrim -v /    
/: 142.4 GiB (152906145792 bytes) trimmed

Вчера запускал и было 170 GiB. Почему так много? И почему при повторном запуске (сразу же) такая картина

sudo fstrim -v /    
/: 142.4 GiB (152906145792 bytes) trimmed

sudo fstrim -v /
/: 160.6 MiB (168415232 bytes) trimmed

sudo fstrim -v /
/: 0 B (0 bytes) trimmed

Спасибо, так и сделал. Может таймер сделать ежедневный а не еженедельный (см. комментарий выше)?

Заодно, пользуясь случаем, спрошу: стоит ли с учетом использования SSD изменить I/O scheduler на noop?

Шо так 12309, шо этак, и вот эти вот два 12309 такие, шо я просто в изумлении. Я использовал noop ещё на тарахтелках, но не могу утверждать, что хоть раз видел профит. Щас вообще внезапно вот так:

 % cat /sys/block/sd?/queue/scheduler 
[mq-deadline] none

Может таймер сделать ежедневный а не еженедельный (см. комментарий выше)?

Сделай ежемесячным, всё равно разницы не увидишь.

Что там у NVME — я вообще хз где смотреть

Да, в общем-то, там же:

$ cat /sys/block/nvme0n1/queue/scheduler      
[none] mq-deadline kyber bfq

Почему так много?

Вообще fstrim — обычно и вовсе идемпотентная операция.

И почему при повторном запуске (сразу же) такая картина

А у тебя ФС запоминает состояние, но только в памяти.

Спасибо. На самом деле я и не пытался. У меня тоже none — может, оно и к лучшему, теоретически меньше говнокода на пути.