Samsung, линуксы, трим – опять как всегда

Хм, у меня 860, пока проблем не наблюдал.

У обладателей Samsung SSD 860 и 870

Я тут.

~$ sudo smartctl -a /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.11.0-27-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 860 EVO 250GB
Serial Number:    S4BFNJ0xxxxxxxx
LU WWN Device Id: 5 002538 e3xxxxxxx
Firmware Version: RVT04B6Q
User Capacity:    250 059 350 016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Sep  5 20:23:49 2021 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       10475
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       683
177 Wear_Leveling_Count     0x0013   097   097   000    Pre-fail  Always       -       44
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   069   050   000    Old_age   Always       -       31
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       196
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       13481774985

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      4569         -

сюрпризы с линуксами

Как увидеть?

опять как всегда

Опять в кривых прошивках виноват линукс?

Опять в кривых прошивках виноват линукс?

У форнира - да, разумеется. Это же хейтер-набрасыватель форнир без логики.

Это буква л.

А так, ППКС.

Это буква л.

Я в курсе )) Попробуй выговори быстро «форнлр» )

хейтер-набрасыватель

Не хейтер, а фанатик-щитпостер.

Я запомнить не могу, а вы про произношение. ;)

Никогда такого не было и вот опять: https://bugs.launchpad.net/ubuntu/ source/linux/ bug/1338706

Да я помню прекрасно, адово матерился на самсунг тогда. Они afaik выпустили обновления прошивки, которые латали только часть проблемы (к слову, у многих тогда проблемы с queued trim вылезли)

Тут всё просто: сокращение от For New Lunar Republic.

Как увидеть?

Если не используешь queued TRIM, то никак.

Видимо, слишком «просто».

Спасибо.

А как узнать, используется оно на машине или нет / как включать и отключать?

А то как раз собирался подобную ссдишку брать.

Или в /etc/cron.* лежит расписание, или есть systemd юниты вроде fstrim.timer/service, или еще как-то.

Спасибо

Тут речь про QTRIM.

Поэтому надо новое ядро (вряд-ли пока есть где-то). Либо самому патчить

https://git.kernel.dk/cgit/linux-block/commit/?id=8a6430ab9c9c87cb64c512e505e8690bbaee190b

виноват?

Это типичное мышление фанатика. Надо найти виновного и на него возложить всю вину.

Есть три стороны в деле. Срочно скажите кто во всём виноват! А потом и в компании конкретной ФИО виновных!

Я всего лишь описываю ситуацию.

Кажись нужен AMD SATA контролёр.

А разве тот патч не ограничивает применение TRIM для 860 и 870 моделей, что повлечёт снижение скорости SSD?

Дык вроде и с Intel'ами & Co тоже не айс, не?

А это случаем не у этой 800-й серии были проблемы с деградацией производительности на TLC моделях: когда давно записанные данные начинали терять в скорости чтения ?

Это то на AMD только? Оригинал новости не читал.

опять как всегда

Как когда?

Как всегда оборудование с гнулинуксом хорошо работает.

А я только хотел покупать. Значит надо брать nvme на 2 ТБ, а не вот это вот всякое говно.

А это случаем не у этой 800-й серии были проблемы с деградацией производительности на TLC моделях

У старых 840 EVO (нищебродная серия) такое было. Исправляли как могли костылями в прошивке.

Я всего лишь описываю ситуацию.

И вот примерно на этом месте ты начинаешь врать. Ты «описываешь ситуацию» с применением языкового манипулирования. В журналистике это называется «editorial bias», а у тебя —

типичное мышление фанатика. Надо найти виновного и на него возложить всю вину

ну собственно всё правильно написал. Проблема типичного фанатика в том, что свой собственный фанатизм он не осознаёт :)

трим спецификация ата, на других железках реализация механизма работает хорошо. Вывод дрова придётся фиксить под особенности железки нет? Под винду они дрова отдельно предоставляют конкретно эти или нет?

Под винду

На сколько понимаю, Windows просто не умеет QTRIM

Ладно тогда про неё забудем. Другие SSD с тримом работают ок? Или с ним у всех железок под линукс плохо из за несоотвецтвия спецификации трим в реализации. Или же это ссд проблемные работают с трим как то по своему с ньюансами что надо учитывать? Вот эти вопросы важны, так как неясно это ssd плохо работают на линукс или линукс плохо работает с ссд. Говно софт или говно железо. Пока не ясно.

Это получается в 5.15

...						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Samsung SSD 860*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM |
						ATA_HORKAGE_NO_NCQ_ON_ATI, },
	{ "Samsung SSD 870*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM |
						ATA_HORKAGE_NO_NCQ_ON_ATI, },
...

прилетит

https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L3999

В журналистике это называется «editorial bias»

А по простому - обыкновенный FUD )

Правильно ли я понимаю, что это повлияет только на команду SATA TRIM (SCSI UNMAP) при удалении файла, если установлена опция discard и не повлияет при вызове fstrim [mountpoint]?

Технически это одно и то же. Но на практике эта фича имеет смысл только когда команды TRIM перемежаются с нормальными командами чтения/записи, т. е. только в первом случае. Во втором случае команд TRIM за единицу времени генерируется настолько много, что они в любом случае забьют собой всю очередь и поставят диск раком.

Соберу новое ядро из linux-next-git, проверю как работает discard, fstrim и blkdiscard на samsung evo 860

А разве не наоборот? Демоны fstrim — это кондовый TRIM раз в неделю (типа как в винде), который был ещё когда этих самсунгов в проекте не существовало, и который ни у кого вопросов не вызывает по причине своей кондовости. В принципе, можно fstrim даже руками запустить и посмотреть, будут ли глюки.
А на самсунгах косяки традиционно вылезают из-за continuous TRIM, который в стандарте есть, но реализован только в Линуксе и по идее должен бесшовно отрабатывать после каждого удаления (если накопитель сообщает, что свободен), но вот как-то с ними глючит из-за каких-то особенностей прошивки.
Так что если есть fstrim по расписанию — по идее carasin как раз может успокаиваться.

ОК, спасибо.

Демоны fstrim — это кондовый TRIM раз в неделю (типа как в винде)

В винде выполняется добивальщик (если жирный запрос будет, то онлайновый забьёт). А так постоянно TRIM работает.

Он выполняется раз в день — добивает не до трименное онлайном и выполняет дефрагментацию (но уже раз в месяц).

Ну и Continuios TRIM и Queued Trim — это совершенно разные вещи. Поэтому беспокоиться есть о чём.

Но если SATA 3.0 или старее, то QTRIM не поддерживается и бага тоже нет.

К примеру. У меня вон 850 PRO.

Он давно заблеклистен в ядре. Да и в добавок у меня старая SATA 3.0.

В итоге QTRIM не работает железобетонно. В итоге дефолтом в Ubuntu раз в неделю выполняется TRIM, и на пару минут диск очень сильно просядает по производительности. Потому что TRIM без очередей почти всё захватывает.

В реальности я за семь лет, только раз это заметил — запустил виртуалку, как раз в эти пару минут в неделю. А она не запускалась минуту…

Если бы у меня поддерживался QTRIM (SATA новее была бы), и в ядре он не был бы заблеклистен. То такой просадки из-за монополизации не было бы. Но с большим риском у меня бы разлетелась бы ФС.

То есть если у тебя ОС выполняет Scheduled TRIM раз в неделю (дефолт Ubuntu, Fedora) — это не спасает тебя от данного бага.

Огонь. Спасибо за пояснения.

проверю как работает discard, fstrim и blkdiscard на samsung evo 860

Работать будет всё одинаково. Просто медленнее. -o discard будет создавать большую просадку производительности под нагрузкой.

См. выше.

«TRIM по расписанию» и «continous TRIM» — это одна и та же технология, одни и те же команды. Сабж о том, что теперь (без queued TRIM) отправка любых команд TRIM на диск будет вызывать существенную просадку производительности в момент отправки этой команды. Когда ты делаешь fstrim, это не играет никакой роли, т. к. диск всё равно встаёт раком примерно на пару минут. А -o discard будет больше просаживать производительность, поэтому без queued TRIM его рекомендуется отключать.

Когда ты делаешь fstrim, это не играет никакой роли, т. к. диск всё равно встаёт раком примерно на пару минут.

Ну так не ты, а великий и могучий systemd таймер ⏱.

А когда именно он захочет сделать это раз в неделю — это хозяин-барин (наверно задокументированно).

«Когда» в смысле «если», а не «в какое время».

А мои гнулинуксы с крутящимися ржавыми блинами работают нормально!

Так вибрация же 😮

В 2021 году как-то совсем уж…

Нету никакой вибрации, это всё маководская пропаганда! От соседней стройки вибрация всё равно на порядки больше.

а резиновые прокладки для чего придумали!