Как проверить работу TRIM на SSD

Ну раз окончание на -ed то видимо триминг успешно осуществился.

Это означает, что TRIM работает или может работать?

Это означает, что он успешно выполняется. Раз в неделю выполняй fstrim и все будет нормально.

а не подскажете как тримать шифрованные разделы? мне

 sudo fstrim / -v 

пишет

fstrim: /: the discard operation is not supported

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

Скрипт: https://pastebin.com/Qpg2n2FR

Есть опция: cryptsetup luksOpen --allow-discards.

Здесь есть скриптец и мануал как проверить

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

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

В шляпе это делается либо опцией discard, либо юнитом fstrim.timer. Поэтому проверьте

systemctl status fstrim.timer

cat /etc/lvm/lvm.conf|grep issue_discards

fstrim: /: the discard operation is not supported

это значит никакого trim нет, у меня так тоже пишет - ничего не зашифровано, винт доисторический ide на 40 pin

благодарю

Хочу проверить, что TRIM запущен и работает, по всем мануалам - в fstab'е разделы должны быть примонтированы с discard

Это один из вариантов. Не самый лучший.

Есть 2 варианта трима.

Первый - прописать discard в fstab, тогда трим будет выполняться при каждом удалении файлов. Однако в зависимости от интерфейса и модели накопителя от этого могут быть самые разные проблемы, вплоть до потери данных.

Второй - периодически делать fstrim. По таймеру, ручками, как душе угодно. Этот вариант предпочтительнее.

Спасибо за ответ.

Спасибо! А без команды fstrim в cron'е трим всё равно будет выполняться? Или команда нужна и трим как процесс идет?

# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:fstrim

# cat /etc/lvm/lvm.conf|grep issue_discards
        # Configuration option devices/issue_discards.
        issue_discards = 0

Вывод по командам такой:

# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:fstrim
[root@apollo16-500 ~]# cat /etc/lvm/lvm.conf|grep issue_discards
        # Configuration option devices/issue_discards.
        issue_discards = 0

0 - это НЕвыполнение или выполнение trim? Немного запуталась, в винде 0 для трима - трим работает, а 1 - трим не работает. Знаю, что в Linux всё по-другому, но может и тут трим как-то выделился?

А без команды fstrim в cron'е трим всё равно будет выполняться?

Не будет. Тебе нужно либо монтировать все ФС с discard, чтобы трим выполнялся при работы с ФС, либо выполнять трим вручную время от времени с помощью fstrim.

Включи fstrim.timer, тогда fstrim автоматически будет выполняться раз в неделю. Опция discard в таком случае ненужна.

А issue_discards вообще в тему при «нормальном» использовании lvm (когда тома более-менее статичны)?

Потому что lvm.conf говорит

# Issue discards to PVs that are no longer used by an LV.
# Discards are sent to an LV's underlying physical volumes when the LV
# is no longer using the physical volumes' space, e.g. lvremove,
# lvreduce. Discards inform the storage that a region is no longer
# used.

У меня лично issue_discards стоит 0, но fstrim успешно отрабатывает на томе lvm и говорит, что потримано столько то гигабайт.

TRIM отключен.

Где доки — четко написано: Docs: man:fstrim, /etc/lvm/lvm.conf.

cron в Шляпе для периодического трима не принято использовать.

Да, все правильно.

Мы не знаем, что с томом будут делать дальше + мы отвечаем не столько ТС, сколько проясняем этот и похожие кейсы.

Эту тонкость с LVM надо держать в голове.

по всем мануалам - в fstab'е разделы должны быть примонтированы с discard У меня в fstab всё по дефолту

Так что мешает прописать в fstab'е discard вместо дефолта? А заодно relatime, чтоб не писать на диск, когда осуществляется только чтение.

а в этом девайсе есть Background Garbage Collection?

Так что мешает прописать в fstab'е discard вместо дефолта?

Здравый смысл.

А заодно relatime

Умение читать документацию.

Так что мешает прописать в fstab'е discard вместо дефолта?

Здравый смысл.

И в чём тут здравый смысл?

А заодно relatime

Умение читать документацию.

И? В документации описаны какие-то программы, имеющиеся на любом сервере и десктопе, которые не будут работать с relatime?

И в чём тут здравый смысл?

1) До SATA 3.1 тримы ставят раком остальной disk IO.

2) Есть куча популярных девайсов (включая даже EVO 850), для которых использование discard'а приводит к потере данных из-за кривой фирмвари.

Так что большинство дистров рекоммендуют дискард без особой необходимости не использовать.

1) До SATA 3.1 тримы ставят раком остальной disk IO.

2) Есть куча популярных девайсов (включая даже EVO 850), для которых использование discard'а приводит к потере данных из-за кривой фирмвари.

У меня samsung 850 evo mz-75e500bw sata III чуть меньше года (поставил в начале года), в fstab прописан discard для всех разделов ext4, раком ничего не встаёт, и данные ни разу не терялись.

Но если такое бывает (о чём я не знал), то, наверно, стоит потестировать конкретный диск с этой опцией, прежде чем использовать её в рабочем режиме и с рабочими данными. Но, имхо, это не повод без тестов от неё отказываться только потому, что у кого-то такое иногда случается.

Про дискард надо понимать, что ты настаиваешь не одну рукоятку вкл/выкл, а целый бутерброд систем, где команда discard проходит сверху вниз.

• Наверху у тебя ФС
• Ниже всякие lvm (в т.ч. thin pool которым тоже принимать команды на discard бывает полезно)
• Ещё ниже шифрование
• И уж совсем внизу SSD.

Если любой из слоев не пробрасывает дискард далее вниз, то ничего не будет.

Отдельный вопрос - как настраивать самый верхний уровень - через таймер/крон или через опцию в фстаб.

У меня samsung 850 evo mz-75e500bw sata III чуть меньше года (поставил в начале года), в fstab прописан discard для всех разделов ext4, раком ничего не встаёт, и данные ни разу не терялись.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drive...

В итоге у тебя non-queued trim, чтобы данные не потерялись. Раком не встает потому что мноо не трешь.

The non-queued nature of the command requires the driver to first wait for all outstanding commands to be finished, issue the TRIM command, then resume normal commands. TRIM can take a lot of time to complete, depending on the firmware in the SSD, and may even trigger a garbage collection cycle

В итоге у тебя non-queued trim, чтобы данные не потерялись.

Спасибо за информацию. Но таки он ведь работает и тримит?

Раком не встает потому что мноо не трешь.

Спасибо за ликбез. Я действительно много пока не тёр. Сейчас у меня лежат несколько здоровых фильмов, которые я давно посмотрел, но продолжаю раздавать, поэтому не удаляю. Когда буду удалять, обязательно потестирую, как будут вести себя другие программы, обращающиеся к диску.

У меня у самого 850 EVO, и fstrim отрабатывает где-то секунд за 5, но это раз в пару недель, так что скорее всего для десктопного использования ничего прямтакого не будет.

Спасибо за инфу.

Однако в зависимости от интерфейса и модели накопителя от этого могут быть самые разные проблемы, вплоть до потери данных.

Вообще-то это про queued trim, который на проблемных ssd заблокирован в ядре.

2) Есть куча популярных девайсов (включая даже EVO 850), для которых использование discard'а приводит к потере данных из-за кривой фирмвари.

Мониторить и оперативно обновлять прошивки надо - ничего не будет теряться.

В итоге у тебя non-queued trim, чтобы данные не потерялись. Раком не встает потому что мноо не трешь.

С багованными ssd неважно, когда он уйдёт ненадолго в себя - при удалении или при вызове fstrim ;)

Отключая discard и полагаясь на fstrim ты просто отдаляешь по времени «уход в себя» ssd при trim'е :)

Если делать fstrim руками, то можно контролировать время ухода в себя. Ну т.е. мне не страшно дать ССД погулять в себе на некоторое время, но если это произойдет внезапно аля перезагрузка вин10 для обновления, тот это будет неприятно.

trim на ssd не нужен, он не даёт буста производительности.

Проверить просто: попробуй восстановить удалённые некоторое время назад файлы. Если не восстанавливаются, то TRIM работает.

TRIM устраняет деградацию производительности из-за забивания ячеек памяти данными, а не делает её буст.

Не нравится слово буст, скажу в твоей терминологии - при отсутсвии trim деградации производительности нет.

Мониторить и оперативно обновлять прошивки надо - ничего не будет теряться.

Я бы не был таким категоричным.

Баги не только находят в прошивках SSD, но и так же в линуксовом ядре.

Поэтому это реально поиск приключений себе на попу.

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

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

discard в fstab ничем не отличается от fstrim. Это просто отложенный по времени trim.

Верно. Но в том то и суть, что проводить опасную операцию постоянно, и проводить её раз в неделю - это разные вещи.

Проводить часто, но понемногу ИМХО лучше, чем раз в неделю помногу. Плюс к тому, пока не работает trim посередине недели, можно наткнуться на такие нехорошие вещи как write amplification и значительное снижение скорости записи из-за цикла «очистка/модификация/запись» для каждой ячейки.

А Монте Карло говорит что niet

Как проверить работу TRIM на SSD (комментарий)