LINUX.ORG.RU

[жж] словил сбойные сектора на nvme ssd

 , , , ,


3

6

Дорогой Уважаемый ЛОР,

Я словил первое в своей жизни проявление сбойных секторов на SSD. Пациент — Samsung SSD 970 EVO 2TB с прошивкой 2B2QEXE7, в эксплуатации примерно год. Пару-тройку дней назад мне почему-то захотелось сделать копию вообще всех данных из домашней директории, включая файлы, которые легко скачать из сети при надобности. Некоторые из этих файлов лежали там с момента миграции на накопитель, без обращений. И при копировании одного из таких файлов программа сказала: «А я, кажись, чот не могу». После того, как потихоньку пришло осознание произошедшего, я глянул в лог и увидел там:

blk_update_request: critical medium error, dev nvme0n1, sector 313199872 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 0

Что интересно, во второй раз файл успешно скопировался. Не знаю, прочитались там настоящие данные или мусор. К сожалению, вот этот конкретный файл повторно скачать оказалось неоткуда. Чтение данных с nvme0n1 по тому адресу выдало какие-то данные, не нули. Тут я решил, что SSD умный, что он понял, что страница не читается стабильно, и увёл её в чулан, на её место подставил новую, а данные всё-таки скопировал. Но на всякий случай решил запустить холостое чтение с блочного устройства. Сбойных блоков оказалось больше. Пробовал читать конкретные места. Зачастую чтение было успешным, но через много чтений всё же происходили ошибки. Попробовал перезаписать место с ошибками чтения теми же данными. Ошибки там прекратились.

В итоге сделал дамп через ddrescue, а потом записал этот дамп обратно. Последующие попытки прочитать накопитель целиком уже никаких ошибок не давали. Сижу вот теперь как на пороховой бочке. Пользоваться дальше немного боязно, но и выбрасывать накопитель, который вроде работает, как-то жалко.

За время тестов в логи свалилось 546 строк с «blk_update_request: critical medium error», но ошибки иногда сыпались так часто, что в сумме набралось 888 «callbacks suppressed». В статусе накопителя написано, что ошибок доступа к носителю было 1484. Так как в логи основной системы не попало происходившее на LiveUSB, можно считать, что числа сходятся. К сожалению, не помню, были ли там ошибки до недавних событий. Всего различных сбойных секторов было 167 штук.

В данных из плохих секторов нашлись обрывки Packages из Debian. Судя по версиям пакетов, эти куски из очень старых Packages, возможно ещё из 2016. Если это так, они приехали во время миграции на накопитель, и с тех пор не перезаписывались и не читались. Один кусок оказался очень похож на файл переводов и нашёлся в /usr/share/locale/gl/LC_MESSAGES/coreutils.mo, который конечно же ни разу не читался с момента последней переустановки пакета coreutils в начале августа 2019.

smartctl:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    1%
Data Units Read:                    162 937 114 [83,4 TB]
Data Units Written:                 65 584 401 [33,5 TB]
Host Read Commands:                 691 234 670
Host Write Commands:                544 796 594
Controller Busy Time:               3 278
Power Cycles:                       719
Power On Hours:                     2 249
Unsafe Shutdowns:                   82
Media and Data Integrity Errors:    1 484
Error Information Log Entries:      1 783
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               41 Celsius
Temperature Sensor 2:               42 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged

Терабайт тридцать-сорок я добавил чтением накопителя во время тестов.

Думаю, из произошедшего можно сделать, как минимум, следующие выводы:

  • полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;
  • чтение такой страницы не заставляет SSD подменять страницу на новую, он с радостью выдаёт ошибку чтения на одном и том же месте много раз подряд;
  • trim не означает очистку всех неиспользуемых блоков ФС, они же меньше страницы. Некоторые данные могут жить в закоулках годами;
  • SSD желательно периодически прочёсывать чтением, чтобы словить сюрпризы пораньше;
  • если такое происходит на TLC 3D V-NAND, страшно подумать, что будет на QLC.

Upd.
Узнал, что в NVMe есть фича 0x10, которая управляет температурами, при которых SSD должен начать тормозить для снижения нагрева. Правда для 970 EVO эти температуры дожны быть в диапазоне 80–82 °C, а попытка установить любые значения кроме 0 для фичи 0x10 завершаются неудачай.


Upd. 11 мая 2021, то есть примерно через год и два месяца после первого раза, появились новые ошибки чтения. При повторном чтении тех же мест ошибки повторялись, но через некоторое время пропали.


Upd. 5 июня 2021. Аккумулятор оказался вздут в той секции, что прилегает к SSD. Видимо, предупреждение о температурном лимите в 65°C на аккумуляторе написано не просто так.

★★★★★

полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;

ошибка в логике примерно здесь, остальная бельчарня базируется на ней

t184256 ★★★★★ ()

Вспомнилась история с Samsung 840 EVO

https://habr.com/ru/post/379235/

https://habr.com/ru/post/362647/

https://habr.com/ru/post/378575/

Проблема будет окончательно решена с помощью регулярной перезаписи данных

.

полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;

Я уж было подумал, что после этого 840 EVO такое больше не повторится.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)

полгода без чтения страницы на SSD достаточно для последующих ошибок чтения

В принципе то же самое, что и на HDD, только в 10-15 раз быстрее.

По идее, нужен какой-то фоновый процесс (на слое фс/md/lvm), который будет медленно на лету обновлять данные на носителе, раз уж он сам не догадывается их регенерировать.

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

Там же умный контроллер, разве он не должен сам перемещать и читать данные?

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

А как их глянуть?

По всей видимости, доступны только последние 64, и те только до выключения питания. Потом лог сбрасывается, остаётся только счётчик общего числа. Через nvme error-log результат в точности тот же.

i-rinat ★★★★★ ()
Ответ на: комментарий от Lordwind

Были ли перерывы в работе, типа оффлайн на несколько месяцев?

Разве что пару дней, не больше.

для серьезных задач eMLC

Ну, например, яндекс маркет показывает, что eMLC и 2280 «в одном флаконе» никто не делает. Да и цены там о-го-го.

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

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

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

новый купи

Жаба душит. Причём жалко даже не новый накопитель покупать, а что старый некуда вставить. Продавать использованные накопители данных я точно не буду, тем более с историей сбоев.

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

Это был главный тег :) Ну и повод нокатить у тебя уже есть. "-- Как адвокат я сделал всё... — Но вы же только нокатили вискаря... — Что смог" (с)

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

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

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

но тема да для клуба знатоков, сарян что влез не шарю, но идея aplse мне покоя не дает я ею восхищен, только вот руки не оттуда растут в этом все и дело, все сваливаю.

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

У меня ритуал введения в эксплуатацию включает в себя тесты SMART’а, если они есть, и деструктивный прогон badblock’ом. Поэтому новые накопители это всегда много потраченного времени. Почти никогда не получается сделать всё разом, поэтому делается в несколько заходов, и требует периодического участия. Жёсткие диски чтобы просто один раз прочитать, требуют пару десятков часов. Твердотельные накопители имеют свойство разогреваться до 100 °C в процессе работы, если им не давать время рассеивать тепло. Поэтому перерывы неизбежны.

Нарушать ритуал, как понимаешь, нельзя.

i-rinat ★★★★★ ()

Так все ломается, серверные SSD тоже. На своей памяти штук 5 уже поменял. Что уж говорить о потребительских SSD.

BACKUP BACKUP BACKUP BACKUP BACKUP
BACKUP BACKUP BACKUP BACKUP BACKUP
BACKUP BACKUP BACKUP BACKUP BACKUP
BACKUP BACKUP BACKUP BACKUP BACKUP
BACKUP BACKUP BACKUP BACKUP BACKUP

bigbit ★★★★★ ()

Думаю, из произошедшего можно сделать, как минимум, следующие выводы: полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;

Вчера я вышел на улицу пописать, через час пошел дождь. Из этого можно сделать вывод, что мочеиспускание на улице вызывает погодные изменения.

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

Тут на форуме много обсуждались страшилки вроде «SSD теряют данные просто так». В них мало кто верил. А кто даже верил, ещё верил в метод предотвращения потерь — просто включать SSD время от времени. Предполагалось, что SSD как-то там сами тестируют ячейки и освежают те, что слишком сильно испортились. Наподобие обновления DRAM.

А тут уже не вилами по воде, а конкретный случай. Есть ячейка, которую я записал полгода назад и больше к ней не обращался. Она теперь сбоит. Другие сбоившие ячейки, данные в которых удалось примерно датировать, были записаны год назад. То есть минимальное время между записью и сбоем чтение всё ещё около полугода. И чтение сбойной страницы не вынуждает SSD двигать данные в свежую страницу.

Да, сбой чтения может быть вызван низким качеством конкретной ячейки. Может быть вызван read disturb. Или ещё какими-нибудь причинами, о механизмах которых я вообще не в курсе. Но это хоть какие-то гипотезы, которые можно опровергать. А если сидеть и играть в нигилизм, никогда никуда не сдвинешься.

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

Ты вроде неглупый мужик, много в чем разбираешься, но конкретно тут ты не прав. Составлять по выборке из 1 частного случая картину по всем ssd это неправильно. Я так же могу сейчас сказать, что у меня evo 860 полтора года под данные, некоторые из которых ни разу не читались с момента записи. Все данные в порядке, а значит отсутствие чтения на длительный период не приводит к деградации или потере файлов.

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

Ну у меня уже 1ссд помер, через 7 лет, правда классически - перестал читаться и определяться. А, ну еще подтормаживать стал в последние дни, а СМАРТ писал - ОК по всем полям.

anonymous ()

Что-то интенсивно пишется/читается.

Проверил у себя:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        44 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    3 996 957 [2,04 TB]
Data Units Written:                 4 906 735 [2,51 TB]
Host Read Commands:                 49 594 113
Host Write Commands:                82 393 919
Controller Busy Time:               417
Power Cycles:                       569
Power On Hours:                     2 513
Unsafe Shutdowns:                   60
Media and Data Integrity Errors:    0
Error Information Log Entries:      135
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               44 Celsius
Temperature Sensor 2:               51 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged
iZEN ★★★★★ ()
Ответ на: комментарий от i-rinat

Предполагалось, что SSD как-то там сами тестируют ячейки и освежают те, что слишком сильно испортились. Наподобие обновления DRAM.

А ведь как хотелось верить, что там какой-то простой RTC (с невысокой точностью), и при обращении к ячейке обновляется временной отпечаток. Первым делом при подаче питания SSD проходится по таблице и, если дельта больше порога, обновляет ячейку. Мне ещё было интересно, сколько нужно ждать, пока SSD после подключения завершит проверку необходимости освежения ячеек. А тут теперь такое.

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

Тов. Троцкий? Вы опять вводите в заблуждение?

Он не первый, кто поднимает данный вопрос. (Некромант) после того, как мнения разделились, интерес утратил в евангелизму исчезающих данных в плоскостях ячеек. Но просто вот человек на нетипичном объеме получил некоторое статистическое событие.

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

Составлять по выборке из 1 частного случая картину по всем ssd это неправильно.

У меня нет большей выборки.

Я так же могу сейчас сказать, что у меня evo 860 полтора года под данные, некоторые из которых ни разу не читались с момента записи. Все данные в порядке, а значит отсутствие чтения на длительный период не приводит к деградации или потере файлов.

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

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

а зачем ты купил на 2ТБ?

Так получилось, что у меня относительно много записей-чтений. А у SSD чем больше объём, тем больше заявленный ресурс. И ещё по общим прикидкам получалось, что мне будет маловато одного терабайта. Так и вышло.

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

Тут на форуме много обсуждались страшилки вроде «SSD теряют данные просто так». В них мало кто верил. А кто даже верил, ещё верил в метод предотвращения потерь — просто включать SSD время от времени.

Что-то я не понял, к твоей проблеме это вообще каким боком?
Налицо отказ отдельных ячеек.

И где полный выхлоп smartctl?

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

Что-то я не понял, к твоей проблеме это вообще каким боком?
Налицо отказ отдельных ячеек.

По-твоему ошибки чтения и потеря данных никак не связаны? Ну окей. Я даже не знаю, как это прокомментировать.

И где полный выхлоп smartctl?

Зачем тебе серийный номер, pci идентификатор, полный объём с точностью до байта, идентификатор единственного пространства имён, размер lba сектора, список поддерживаемых необязательных команд и температура, при которой выдаётся предупреждение? Мне интересно, что ты с ними планируешь делать. :)

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

температура, при которой выдаётся предупреждение

Кстати, это интересно. Может он у тебя при 70°C запекался. С прогревом до 100.

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

В обычную нагрузку не входит чтение или запись двух терабайт за один заход, так что сомневаюсь, что температура часто поднималась до таких значений. К сожалению, прикрутить мониторинг nvme к collectd так руки и не дошли, так что исторических данных нет.

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

По-твоему ошибки чтения и потеря данных никак не связаны? Ну окей. Я даже не знаю, как это прокомментировать.

Ты вроде адекватный, но горе повлияло на способность следовать контексту. Бывает.

Зачем тебе
Там написано 82 °C

Сам спросил, сам ответил.
Экспоненту выхода из строя полупроводников в зависимости от температуры нагуглить вроде несложно.

Если там целый год было 80, то это если не основная причина, то точно сопутствующий фактор.

aidaho ★★★★★ ()