[Teror]

На usbdev говорят, что нет прошивки на этот контроллер (май 2024г). Софта для прошивки, как пишут, тоже нет, но можно стандартным способом залить через JTAG. Но заливать нечего, так что... »

спасибо, интересно а что за JTAG?

Это может стоить сотни денег и результат не гарантируется. Иначе - нет смысла. И вбить в себе в глупую башку "я всегда буду резервировать данные". »

понятно, на самом деле это не мой диск, я всегда всем говорю резервировать данные, но люди это понимают слишком поздно...с hdd я понял проще данные восстановить

Но учитывая ваши действия и сколько времени прошло, скорее всего, по факту там ничего уже не осталось из-за фоновой работы TRIM. »

я знаю про перезапись данных что если поверх записать то данные мало вероятно что восстановятся, но не знал что TRIM работает в фоне даже если диск " не активный"

[dmitryst]

интересно а что за JTAG? »

JTAG

hdd я понял проще данные восстановить »

так-то да, но есть нюансы, как говорится.

[Cereal Keeler]

так-то да, но есть нюансы, как говорится. »

Ага, SMR сложнее.

понятно, на самом деле это не мой диск, я всегда всем говорю резервировать данные, но люди это понимают слишком поздно... »

Кстати, наиболее приемлемую для большинства случаев стратегию резервирования 3-2-1 разработал не инженер, не админ, а профессиональный фотограф, потерявший свои фоточки. Он прошёл по граблям, сделал выводы и разработал стратегию, чтобы это не делать другим, но как говорится, пока жареный петух не придёт по лично твою задницу...

Стратегия резервирования 3-2-1

3 - иметь как минимум 3 копии важных данных
2 - использовать как минимум 2 разных физических хранилища данных для разных копий. Пример - один набор копий хранить на одном жёстком диске, другой - на другом.
1 - как мимнимум одна из копий должна быть offsite, то есть храниться в другом помещении/городе/стране. Проще и дешевле всего для этого арендовать облачное хранилище.

3-2-1 не покрывает вопросы RPO (Recovery Point Objective) и RTO (Recovery Time Objective), но для большинства домашних пользователей они и не критичны.

я знаю про перезапись данных что если поверх записать то данные мало вероятно что восстановятся, но не знал что TRIM работает в фоне даже если диск " не активный" »

Тут немного не так. TRIM это команда от хоста произвести "уборку". Но "уборку" (Garbage Collection, GC) время от времени проделывает и сам накопитель, вернее, его контроллер, для чего достаточно чтобы он был просто запитан, даже не подключен.

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

[dmitryst]

пациенты откисали из-за глюков. »

самое обидное, что после перепрошивки они могут работать годами. У самого лежит парочка таких.

[Cereal Keeler]

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

[Teror]

Вообще по идее при сбоях контроллер должен перевести накопитель в режим только для чтения, как раз на случай, если данные нужно с него восстановить, но то зависит от контроллера и его прошивки, в которых бывают ошибки. Не было б ошибок, не было б и катастрофических сбоев – ни разу не видел SSD, который бы умер от износа, все пациенты откисали из-за глюков. »

а это правда что сбои на ssd чаще всего "виновата служебная область"? либо сама прошивка контролера слетает

цитата

Скрытый текст

Почему SSD выходят из строя, если в SMART всё хорошо

Казалось бы, даже 20-30 циклов перезаписи – вполне приличная цифра, а уж 1000-1500 – и вовсе величина, для обычного пользователя запредельная. Если умножить на ёмкость накопителя в 512 ГБ, на него нужно записать 10-15 ТБ до того, как начнётся хоть сколько-нибудь заметная деградация ячеек. Если же брать цифру производителя, то данные и вовсе можно писать сплошным потоком в течение многих лет. Однако даже с учетом использования специальных алгоритмов «равномерности записи», проблемы наступают гораздо раньше.

Узким местом каждого накопителя является так называемая служебная область. Служебная область – это ограниченная фиксированная область, выделенная для хранения прошивки (управляющей микропрограммы) и служебных структур. Эта область постоянна и имеет ёмкость порядка 4-12 Гбайт. В ней хранятся все служебные структуры — модули (таблицы переназначенных блоков, части микрокода, отвечающие за хранение пароля, атрибуты SMART и т.д.)

Проблема же в том, что каждый раз при записи информации в доступной пользователю части накопителя меняются и служебные структуры, отвечающие за информирование контроллера о переводе физических блоков в логические. В зависимости от характера использования накопителя (запись последовательности данных большим куском или множества мелких операций записи) нагрузка на служебную зону, находящуюся по фиксированному адресу, может существенно вырасти. Для служебной зоны не работают алгоритмы равномерности записи (wear levelling); она не может быть переадресована при износе ячеек.

В результате в определённых сценариях использования (к примеру, SSD используется для активной работы базы данных с огромным числом транзакций, которые изменяют буквально несколько байт данных – но перезаписывают всё равно целый блок) уже через несколько месяцев (а не лет!) современные SSD начинают приходить в негодность. Закончиться всё может печально: совершенно неожиданно, при отличных показателях диагностики SMART и параметре износа порядка единиц процентов («оставшийся ресурс: 99%») SSD может просто пропасть из системы. Связано это с тем, что количество неисправных ячеек в служебной области увеличивается настолько, то коды ЕСС коррекции контроллера уже не могут их скорректировать, и SSD прекращает определяться в BIOS или показывать полную емкость.

Происходит следующий циклический процесс. Контроллер подгружает микропрограмму с NAND микросхем; микропрограмма содержит критическое количество ошибок; контроллер получает ошибку о невозможности считать микропрограмму; контроллер пробует прочитать ее снова и подгрузить в ОЗУ; снова получает ошибку; и так до бесконечности.

Как правило, наиболее частой неисправностью является выход из строя самого важного модуля – «транслятора», который транслирует адреса физических блоков в логические. С точки зрения пользователя это может выглядеть как катастрофическое падение определяемой ёмкости накопителя – к примеру, видны 2 МБ или 980 МБ вместо полноценных 512 ГБ.

[Cereal Keeler]

а это правда что сбои на ssd чаще всего "виновата служебная область"? либо сама прошивка контролера слетает »

Очень упрощённо и большей частью неверно. Слетает не сама прошивка, а FTL - Flash Translation Layer, таблица, сопоставляющая адреса LBA физическим адресам в NAND. А прошивка при невозможности считать FTL переходит в аварийное состояние, диск не работает.

Проблема хранения FTL действительно сложна и интересна. Хоть её размер относительно невелик, порядка десятков мегабайт, но туда действительно много пишется, читается и сбой FTL = безвовзвратная потеря даных. То есть, данные никуда не деваются, но найти их не представляется возможным. При выравнивании износа, уборке мусора, FTL тоже должна обновляться, так как меняется физическое расположение данных в NAND. В ход идут разные ухищрения, вроде журналов, циклического перемещения служебной области по мере записи и т.п. В общем, утверждать про какую-то фиксированную "служебную область", износ в которой вызывает сбой FTL, я бы не стал. Ещё, для снижения нагрузки эта таблица мапится в DRAM память, либо на самом диске, либо в DMA хоста в случае безбуферников, но тут возникает проблема, что делать в случае сбоев, например, питания. И там тоже идут в ход ухищрения, вроде конденсаторов, обеспечивающих работу контроллера в случае пропажи питания, на миллисекунды, чтобы успеть дописать.

Всё очень сложно, неудивительно, что сбои не редкость и они вовсе не обязательно связаны с износом какой-то "служебной области". Тем более, что после попытки перепрошивки сбойного диска тот часто продолжает работать как ни в чём ни бывало. Будь фиксированная служебная область у таких экземпляров ушатана в ноль, восстановить работоспособность не получалось бы.

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

[Teror]

Очень упрощённо и большей частью неверно. Слетает не сама прошивка, а FTL - Flash Translation Layer, таблица, сопоставляющая адреса LBA физическим адресам в NAND. А прошивка при невозможности считать FTL переходит в аварийное состояние, диск не работает. Проблема хранения FTL действительно сложна и интересна. Хоть её размер относительно невелик, порядка десятков мегабайт, но туда действительно много пишется, читается и сбой FTL = безвовзвратная потеря даных. То есть, данные никуда не деваются, но найти их не представляется возможным. При выравнивании износа, уборке мусора, FTL тоже должна обновляться, так как меняется физическое расположение данных в NAND. В ход идут разные ухищрения, вроде журналов, циклического перемещения служебной области по мере записи и т.п. В общем, утверждать про какую-то фиксированную "служебную область", износ в которой вызывает сбой FTL, я бы не стал. Ещё, для снижения нагрузки эта таблица мапится в DRAM память, либо на самом диске, либо в DMA хоста в случае безбуферников, но тут возникает проблема, что делать в случае сбоев, например, питания. И там тоже идут в ход ухищрения, вроде конденсаторов, обеспечивающих работу контроллера в случае пропажи питания, на миллисекунды, чтобы успеть дописать. Всё очень сложно, неудивительно, что сбои не редкость и они вовсе не обязательно связаны с износом какой-то "служебной области". Тем более, что после попытки перепрошивки сбойного диска тот часто продолжает работать как ни в чём ни бывало. Будь фиксированная служебная область у таких экземпляров ушатана в ноль, восстановить работоспособность не получалось бы. Усугубляет и то, что имплементации этого всего разные в разных контроллерах, алгоритмы работы и их реализации - где и как хранится FTL, как обеспечивается защита от сбоев - представляют собой коммерческую тайну, потому подробной инфы в открытом доступе просто нет. »

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

[Cereal Keeler]

интересно, а какая тип памяти по вашему самая лучшая ? »

В смысле какая? SLC, MLC, TLC, QLC? Первые две давно практически не доступны на потребительском рынке, TLC лучше QLC, но дороже в пересчёте на единицу хранения.

когда брать ссд придётся чтобы знать на что ориентироваться »

О конкретных производителях и моделях флеш-памяти нет смысла говорить - производители ссд используемые модели не указывают, максимум тип - TLC или QLC, а также меняют применяемые чипы памяти, тоже не удосуживаясь об этом никого уведомлять. К примеру, читаете вы обзор годовой давности какого-нибудь ссд, там пишут, что используется 64-слойная TLC от Micron. Покупаете его, а там 96-слойный Hynix. Такое сейчас норма. Узнать, какая конкретно память тебе досталась, можно только после покупки, либо при визуальном осмотре, либо посредством специального ПО.