Media errors ssd
Приветствую.
Проблема с относительно новым ADATA SX8200PNP 1TB.
SSD стоял как системный, записал всего то пару терабайт.
Сначало заметил ошибки CRC на чтении файла, глянул в smart – там с десяток Media Errors.
Решил просканировать “поверхность” на “битые” сектора и вот тут пошли массово ошибки Media Errors. Сейчас набралось +8000 ошибок.
Нагуглил что media errors может быть если данные ячейки накопителя “забылись” или “испортились”, и нужно перезаписать “битые” ячейки (но это не точно).
Но при тесте ячеек через Victoria или HDDTune диск через некоторое отваливается – ssd физически недоступен ни в биос, ни в винде.
Помогает только выкл-вкл компа. Далее опять, при тесте через некоторое время отваливается.
При полном сканировании в утилите ADATA SSD Toolbox выскакивает ошибка на определенном % и остановка теста.
Вопросы.
Может кто сталкивался с такой проблемой, неужто диск помирает?
Что за ошибки показывает этот атрибуи Media Errors (кое где идут как Media and Data Integrity Errors)?
Почему отваливается диск? (что интресно, при одиночном Media Errors отвала нет, только при массовом сканировании).
Ответ
ИнфоОтветить2 месяца назад / 12 февраля 2023 18:15
*Claymore*
Запоздал, но отвечу.
Пока решил проблему только полным стиранием Secury Erase из биоса или в утилите Adata.
Сейчас около 1ТБ записал, переодически сканирую поверхность викторией, ошибки Media Errors не увеличиваются.
Думаю проблема не в памяти ( у меня 136 слойная Samsung, а контроллер такой же), а в контроллере.
Словил сбойные сектора на nvme ssd
Я словил первое в своей жизни проявление сбойных секторов на 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.
Терабайт тридцать-сорок я добавил чтением накопителя во время тестов.
Думаю, из произошедшего можно сделать, как минимум, следующие выводы:
полгода без чтения страницы на SSD достаточно для последующих ошибок чтения;
чтение такой страницы не заставляет SSD подменять страницу на новую, он с радостью выдаёт ошибку чтения на одном и том же месте много раз подряд;
trim не означает очистку всех неиспользуемых блоков ФС, они же меньше страницы. Некоторые данные могут жить в закоулках годами;
SSD желательно периодически прочёсывать чтением, чтобы словить сюрпризы пораньше;
если такое происходит на TLC 3D V-NAND, страшно подумать, что будет на QLC.
