LINUX.ORG.RU

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

fernandos ★★★
()

У обладателей 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         -

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

Как увидеть?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

виноват?

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

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

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

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

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

carasin ★★★★★
()

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

DawnCaster ★★
()

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

int13h ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от fornlr

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

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

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

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

zemidius
()
Последнее исправление: zemidius (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. выше.

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

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

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

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

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

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

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

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