LINUX.ORG.RU
ФорумAdmin

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

 ,


2

2

Добрый вечер, ставлю на SSD 256гБ Centos 7. Разделы задала по дефолту.

Отключила swap через fstab.

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

У меня в fstab всё по дефолту:

# cat /etc/fstab

/dev/mapper/centos01-root /                       xfs     defaults        0 0
UUID=e8b8512f-6d63-4dbb-a352-d54c5ad04c3a /boot                   xfs     defaults        0 0
/dev/mapper/centos01-home /home                   xfs     defaults        0 0
#/dev/mapper/centos01-swap swap                    swap    defaults        0 0
tmpfs   /var/cache/yum tmpfs   defaults # добавила из мануала - весь кэш перенести в ОЗУ

Нашла, что можно проверить TRIM, выполнив команду:

# fstrim / -v
/: 48,9 GiB (52531802112 bytes) trimmed
# fstrim /home -v
/home: 171,8 GiB (184425562112 bytes) trimmed

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

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

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

Kron4ek ★★★★ ()

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

 sudo fstrim / -v 

пишет

fstrim: /: the discard operation is not supported
anonymous ()

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

systemctl status fstrim.timer
И убедитесь, что LVM тоже поддерживает это
cat /etc/lvm/lvm.conf|grep issue_discards

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

fstrim: /: the discard operation is not supported

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

amd_amd ★★★ ()

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

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

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

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

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

infine ()
Ответ на: комментарий от Kron4ek

Спасибо! А без команды 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
manik207 ()
Ответ на: комментарий от anonymous

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

# 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 всё по-другому, но может и тут трим как-то выделился?

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

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

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

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

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

А 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 и говорит, что потримано столько то гигабайт.

infine ()
Ответ на: комментарий от manik207

TRIM отключен.

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

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

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

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

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

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

anonymous ()

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

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

aureliano15 ★★ ()

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

Minona ()
Ответ на: комментарий от aureliano15

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

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

А заодно relatime

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

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

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

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

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

А заодно relatime

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

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

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

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

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

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

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

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

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

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

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

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

aureliano15 ★★ ()

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

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

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

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

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

У меня 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

infine ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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