LINUX.ORG.RU
ФорумAdmin

LUKS+LVM+TRIM (Samsung 860 Evo)

 , , , ,


1

2

Вчера случайно обнаружил, что у меня не работает TRIM.

|-----------------------|
|    Samsung 860 EVO    |
|-----|-------|---------|
| EFI | /boot | LUKS    |
|-----|-------| └─ LVM  |
              |    └─ / |
              |---------|

Не работает fstrim:

sudo fstrim -v /
fstrim: /: the discard operation is not supported

Arch wiki:

Solid state drive users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the discard option unless you override the default.

cat /etc/crypttab                  
sda3_crypt UUID=be8c51fe-e99a-46fa-a085-63d117a8eb2e none luks

Arch wiki:

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

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

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

★★★★★

Ответ на: комментарий от anonymous

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

aquadon ★★★★★ ()

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

Black_Shadow ★★★★★ ()
Ответ на: комментарий от anonymous

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

aquadon ★★★★★ ()
Ответ на: комментарий от chaos_dremel
NAME              DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                      0      512B       2G         1
├─sda1                   0      512B       2G         1
├─sda2                   0      512B       2G         1
└─sda3                   0      512B       2G         1
  └─sda3_crypt           0      512B       2G         0
    └─Debian-root        0      512B       2G         0
aquadon ★★★★★ ()

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'ом по расписанию.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

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

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

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

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

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

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

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

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

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

aquadon ★★★★★ ()
Последнее исправление: aquadon (всего исправлений: 3)
Ответ на: комментарий от aquadon

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от aquadon

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

Deleted ()
Ответ на: комментарий от intelfx

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

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

aquadon ★★★★★ ()
Ответ на: комментарий от aquadon

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

Deleted ()
Ответ на: комментарий от aquadon

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Если нет, и суммарный объём записей на диск за период между двумя запусками (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
aquadon ★★★★★ ()
Последнее исправление: aquadon (всего исправлений: 1)
Ответ на: комментарий от aquadon

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

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

 % cat /sys/block/sd?/queue/scheduler 
[mq-deadline] none
Видать само, потому что в cmdline так и торчит «elevator=noop». Что там у NVME — я вообще хз где смотреть, но вроде работает нормально.

anonymous ()
Ответ на: комментарий от aquadon

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

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

anonymous ()
Ответ на: комментарий от aquadon

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

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.