A command which checks that trim is working?
I have installed Ubuntu 14.04 LTS 64bit, and would like to make sure that TRIM is enabled (as much as I know — it is enabled by default). Is there some sort of command which would help me to find out if it is working correctly?
3 Answers 3
You can perform a sudo fstrim -v / (replace «/» with other mountpoints, if you have any), to check if fstrim gives any errors. If it doesn’t, type in cat /etc/cron.weekly/fstrim which should give you an output like:
#!/bin/sh # call fstrim-all to trim all mounted file systems which support it set -e # # This only runs on Intel and Samsung SSDs by default, as some SSDs with # faulty firmware may encounter data loss when running fstrim under high I/O # load (e. g. https://launchpad.net/bugs/1259829). You can append the # --no-model-check option here to disable the vendor check and run fstrim on # all SSD drives Like this (remove the hash): #exec fstrim-all --no-model-check exec fstrim-all If it does, it means, that your Ubuntu automatically recognized that you have an SSD and will trim it once a week as a cron job.
If you like to optimize your system for SSD, check out this article.
I would suggest that a more direct, if somewhat more complex, way to ensure that trim is working is by creating a file, identifying precisely where this file is stored, checking the contents of the file at this location, deleting the file, and then re-checking the contents of the file’s location. If trim is working, the original contents of the file will have been replaced by zeros. The method and the specific commands to conduct this test are documented at: http://andyduffell.com/techblog/?p=852. A specific example of the technique is provided at: https://linuxnorth.wordpress.com/2014/03/18/trim-your-ssd-down-to-size/
On 18.04, you may check it in syslog:
cat /var/log/syslog | grep -a fstrim | tail if you see recent dates and all your SSD’s mountpoints, it’s working. Sample output:
Oct 1 14:54:55 justapc fstrim[769]: /home: 80,1 GiB (86008037376 bytes) trimmed Oct 1 14:54:55 justapc fstrim[769]: /boot: 360,2 MiB (377663488 bytes) trimmed Oct 1 14:54:55 justapc fstrim[769]: /: 16,3 GiB (17486880768 bytes) trimmed Oct 8 08:16:01 justapc fstrim[792]: /home: 76,8 GiB (82423615488 bytes) trimmed Oct 8 08:16:01 justapc fstrim[792]: /boot: 360,1 MiB (377634816 bytes) trimmed Oct 8 08:16:01 justapc fstrim[792]: /: 15,9 GiB (17038168064 bytes) trimmed Oct 8 08:16:44 justapc ureadahead[283]: ureadahead:trimage_trimage.png: Ignored relative path Oct 15 20:14:00 justapc fstrim[749]: /home: 73,5 GiB (78863814656 bytes) trimmed Oct 15 20:14:00 justapc fstrim[749]: /boot: 360,1 MiB (377634816 bytes) trimmed Oct 15 20:14:00 justapc fstrim[749]: /: 16 GiB (17104076800 bytes) trimmed To be sure of any possible errors, verbose fstrim manually:
for mountpoint in $(cat /etc/fstab | awk '/ext9/ '); do sudo fstrim -v "$mountpoint"; done Как проверить работу TRIM на SSD
Добрый вечер, ставлю на 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 работает или может работать?
Ну раз окончание на -ed то видимо триминг успешно осуществился.
Это означает, что TRIM работает или может работать?
Это означает, что он успешно выполняется. Раз в неделю выполняй fstrim и все будет нормально.
а не подскажете как тримать шифрованные разделы? мне
fstrim: /: the discard operation is not supported
Есть опция: cryptsetup luksOpen —allow-discards.
Здесь есть скриптец и мануал как проверить
ism ★★★ ( 28.11.18 21:40:56 MSK )
Последнее исправление: ism 28.11.18 21:41:03 MSK (всего исправлений: 1)
В шляпе это делается либо опцией 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
Это один из вариантов. Не самый лучший.
Первый — прописать 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 = 00 — это НЕвыполнение или выполнение 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 и говорит, что потримано столько то гигабайт.
Где доки — четко написано: Docs: man:fstrim, /etc/lvm/lvm.conf.
cron в Шляпе для периодического трима не принято использовать.
Мы не знаем, что с томом будут делать дальше + мы отвечаем не столько ТС, сколько проясняем этот и похожие кейсы.
Эту тонкость с LVM надо держать в голове.
по всем мануалам — в fstab’е разделы должны быть примонтированы с discard У меня в fstab всё по дефолту
Так что мешает прописать в fstab’е discard вместо дефолта? А заодно relatime, чтоб не писать на диск, когда осуществляется только чтение.
а в этом девайсе есть Background Garbage Collection?
Так что мешает прописать в fstab’е discard вместо дефолта?
Умение читать документацию.
Так что мешает прописать в fstab’е discard вместо дефолта?
И в чём тут здравый смысл?
Умение читать документацию.
И? В документации описаны какие-то программы, имеющиеся на любом сервере и десктопе, которые не будут работать с 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.
Если любой из слоев не пробрасывает дискард далее вниз, то ничего не будет.
Отдельный вопрос — как настраивать самый верхний уровень — через таймер/крон или через опцию в фстаб.
legolegs ★★★★★ ( 29.11.18 14:31:04 MSK )
Последнее исправление: legolegs 29.11.18 14:32:05 MSK (всего исправлений: 1)
У меня samsung 850 evo mz-75e500bw sata III чуть меньше года (поставил в начале года), в fstab прописан discard для всех разделов ext4, раком ничего не встаёт, и данные ни разу не терялись.
В итоге у тебя 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, но это раз в пару недель, так что скорее всего для десктопного использования ничего прямтакого не будет.