Проблемы с дисками, восстановление данных, Жесткими, твердотельными, мягкотелыми, круглыми, квадратными Опции

[Allex]

И поэтому они тоже могут быть подвержены своеобразному пенлинг багу и именно его и лечат стиранием.

Не вполне понял, о каком именно баге речь.

[Datarecover]

Не вполне понял, о каком именно баге речь.

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

[Allex]

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

Я пока что ничего "ошибкой трансляции" не называл.

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

Тормоза и транслятор связаны совершенно другим механизмом: при сильной фрагментации стркутур транслятора для нахождения актуального физического адреса данных запрошенного LBA поиск по транслятору выливается в перебор нескольких его порций, так как в оперативной памяти он весь все равно не помещается. И чем меньше оперативная память и чем более раздут транслятор - тем этих порций нужно прочитать больше. Соответственно, на поиск данных запрошенного LBA тратится куда больше времени - оттуда и тормоза.

Когда у тебя записан большой кусок данных линейно - записи о последовательных LBA в трансляторе оказываются рядом, и после первого обращения к этому куску транслятора (пусть его и нужно было поискать, несколько раз обратясь к флешу) и подгрузки его из флеша в DRAM остальные находятся сразу же, и скорость чтения определяется практически скоростью подачи данных из флеша. Более того, так как запись шла линейно - то и данные последовательных LBA укладывались рядом, по 32 LBA в одну страницу записи. То есть - как только хост обратился за первым LBA из такого последовательного потока - в буфер прочитались все 32, и отдача их на следующие запросы будет вестись уже не из флеша, а из буфера самого контроллера. Таким образом - после первого относительно долгого поиска, дальнейшие данные отдаются в темпе чтения страниц с флеша: страницу в буфер всосали, и ее всю на очередные 32 запроса хосту и отправили.

Теперь посмотрим на картинку, когда запрос на чтение попадает на участок транслятора, забитый мелкоблочными обращениями. Чтобы найти физический адрес наших данных, контроллеру нужно прочитать пусть, к примеру, четыре ссылки на участки транслятора, то есть - прочитать четыре 16-килобайтные страницы, и, найдя нужный адрес, прочитать страницу с данными, пятую. На запрос следующего LBA - процесс придется повторить, потому как он не попал в этот же участок транслятора, и на то, чтобы его отдать хосту, нужно прочитать еще пять страниц флеша. И так далее... То есть, на то, чтобы отдать хосту каждые 512 байт, контроллеру с флеша нужно прочитать 80 килобайт, скорость упала в 160 раз.

Кстати - понимание этого механизма позволяет придумать еще один дополнительный превентивный способ сильно снизить вероятность такого "замучивания" транслятора. Если при разметке тома задать ему не быстрое, а полное форматирование, то все LBA тома пропишутся в транслятор последовательно, и далее структура транслятора фрагментироваться уже не будет. Можно также после быстрого форматирования прописать весь объем тома последовательной записью, например, файловым тестом записи HD Tune Pro.

[Datarecover]

Я пока что ничего "ошибкой трансляции" не называл.

ну "замучиванием" ))

Кстати - понимание этого механизма позволяет придумать еще один дополнительный превентивный способ сильно снизить вероятность такого "замучивания" транслятора. Если при разметке тома задать ему не быстрое, а полное форматирование, то все LBA тома пропишутся в транслятор последовательно, и далее структура транслятора фрагментироваться уже не будет. Можно также после быстрого форматирования прописать весь объем тома последовательной записью, например, файловым тестом записи HD Tune Pro.

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

Я не понимаю как эти действия повлияют снижение "замучивания".

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

Когда у тебя записан большой кусок данных линейно - записи о последовательных LBA в трансляторе оказываются рядом, и после первого обращения к этому куску транслятора (пусть его и нужно было поискать, несколько раз обратясь к флешу) и подгрузки его из флеша в DRAM остальные находятся сразу же, и скорость чтения определяется практически скоростью подачи данных из флеша. Более того, так как запись шла линейно - то и данные последовательных LBA укладывались рядом, по 32 LBA в одну страницу записи. То есть - как только хост обратился за первым LBA из такого последовательного потока - в буфер прочитались все 32, и отдача их на следующие запросы будет вестись уже не из флеша, а из буфера самого контроллера. Таким образом - после первого относительно долгого поиска, дальнейшие данные отдаются в темпе чтения страниц с флеша: страницу в буфер всосали, и ее всю на очередные 32 запроса хосту и отправили.

Теперь посмотрим на картинку, когда запрос на чтение попадает на участок транслятора, забитый мелкоблочными обращениями. Чтобы найти физический адрес наших данных, контроллеру нужно прочитать пусть, к примеру, четыре ссылки на участки транслятора, то есть - прочитать четыре 16-килобайтные страницы, и, найдя нужный адрес, прочитать страницу с данными, пятую. На запрос следующего LBA - процесс придется повторить, потому как он не попал в этот же участок транслятора, и на то, чтобы его отдать хосту, нужно прочитать еще пять страниц флеша. И так далее... То есть, на то, чтобы отдать хосту каждые 512 байт, контроллеру с флеша нужно прочитать 80 килобайт, скорость упала в 160 раз.

Спасибо я попробую реализовать эти тесты на R.Tester и посмотрю.

[Allex]

ну "замучиванием" ))

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

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

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

Я не понимаю как эти действия повлияют снижение "замучивания".

Гм. Я почему-то думал, что при полном форматировании сначала дается команда записи LBA, а потом проверяется, что там записалось...

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

[Datarecover]

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

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

Гм. Я почему-то думал, что при полном форматировании сначала дается команда записи LBA, а потом проверяется, что там записалось...

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

В принципе пока можно понять, что самым воспроизводимым тестом есть тест с отлеживанием и вполне покажет состояние. Или просмотр состояние сервисными утилитами (если уже они есть).Если проблема не в чипах то требуется профилактика. Как профилактика использование SE и раскатка образа с прописью все поверхности. Меня до сих пор терзают сомнения по поводу последнего метода , но объяснения звучат здраво и факты есть (главное чтобы были еще подтверждены временем).

[Spleen]

Доброго !

Один из винтов в рэйде 0 начал сыпаться. Гарантия кончилась.
Без разборки/диагностики по СМАРТ не понять какого рода проблема ?

Начал очень долго читать некоторые файлы (при копировании скорость может эпизодически падать в 10-500 раз, потом восстанавливаться, фильмы некоторые стали кое-где подглючивать, изредка фото долго открываются)

[southman]

По параметрам 05, С4 и С5 ясно, что диск посыпался. 25к часов наработки вполне нормальный срок для такого финала.
Что с ним делать? Определенно так пользовать нельзя - так что сливать данные (рейд0 не дает избыточности по месту, на одном диске не поедет) и искать новые диски или забить на рейд.
А конкретно этот или в ведро продавать как есть или проводить профилактику.

Еще интересно было бы СМАРТ второго увидеть.

[Spleen]

По параметрам 05, С4 и С5 ясно, что диск посыпался. 25к часов наработки вполне нормальный срок для такого финала.
Что с ним делать? Определенно так пользовать нельзя - так что сливать данные (рейд0 не дает избыточности по месту, на одном диске не поедет) и искать новые диски или забить на рейд.
А конкретно этот или в ведро продавать как есть или проводить профилактику.

Еще интересно было бы СМАРТ второго увидеть.

Немного обновил бэкап, и сразу по СМАРТУ стало заметно (копирнул гигов 400, не более)




На втором винте есть пара событий, но за ~2 года больше не появлялось, цифры не стали расти:

[southman]

Немного обновил бэкап, и сразу по СМАРТУ стало заметно (копирнул гигов 400, не более)

» Нажмите, чтобы показать спойлер - нажмите опять, чтобы скрыть... «

- чтение у первого так себе, но Raw read указывает на ошибки в процессе чтения с пластин, которые были исправлены так или иначе. Я бы копировал дальше и не ждал пока отвалится на совсем (такое реально в любой момент). Так как плата на этих дисках уже имеет пружинный коннектор, то проблем окисления площадок тут нет, так что диску скорее всего уже привет и без серьезного рефарба и селф-скана не обойтись, что есть мазохизм на 6Тб.

На втором винте есть пара событий, но за ~2 года больше не появлялось, цифры не стали расти:

» Нажмите, чтобы показать спойлер - нажмите опять, чтобы скрыть... «

есть переназначенные сектора (21шт. за 1 событие), но пендинг 18 шт это проблема - при попытке записи в них получим ошибку CRC и ОС прервет процедуру. Так что прогнать полный формат или цикл записи полезно для этого диска, с целью получить в С5 заветный 0.

[Maxxximus]

WD5000HHTZ VelociRaptor, пластмасска(смотреть скрины) осталась в старом блоке и подключение теперь не возможно + пытаясь наколхозить ее замену(так как извлечь ее не вышло она раскрошилась) были погнуты(хотя и не значительно ножки) так что возможно потребуется замена платы. Ищу мастера со скилами и запчастями для осуществления ремонта.

[KoNoRIMCI]

Может стоит отдельно поискать и купить "Western Digital WDSL00 SATA IcePack 3.5" Mounting Kit Frame"?

Или саму плату выкрутить и отдать на ремонт, пусть разъём заменят.

Это же просто карман/переходник.

[Maxxximus]

Может стоит отдельно поискать и купить "Western Digital WDSL00 SATA IcePack 3.5" Mounting Kit Frame"?

Или саму плату выкрутить и отдать на ремонт, пусть разъём заменят.

Это же просто карман/переходник.

спасибо уже гуглю, а подскажите для того что бы снять плату ничего кроме ключика не нужно?

[KoNoRIMCI]

Нет. Сначала снимите сам диск, открутив четыре винта, а только потом плату.

Диск вытаскивается сдвигом от разъёма.

https://www.youtube.com/watch?v=m3akLvshwz4&t=68s

[Maxxximus]

Нет. Сначала снимите сам диск, открутив четыре винта, а только потом плату.

Диск вытаскивается сдвигом от разъёма.

https://www.youtube.com/watch?v=m3akLvshwz4&t=68s

спасибо так и сделал, нашел у друга карман подключил но винт делает 2 щелчка и вырубается что значит тему перепрофилируем в ремонт

[southman]

спасибо так и сделал, нашел у друга карман подключил но винт делает 2 щелчка и вырубается что значит тему перепрофилируем в ремонт

Диск у вас - редкий зверь Velociraptor, которому кроме питания 5В требуется и 12В, которых нет в 2.5" карманах юсб без внешнего питания.
Советую подключить диск по сата стандартно к ПК.

Если нет результата, значит диску очень плохо - щелчки никогда не бывают просто так.
Восстановление будет тоже весьма затратным - ответил в ПМ.

[Spleen]

Немного обновил бэкап, и сразу по СМАРТУ стало заметно (копирнул гигов 400, не более)

Ещё чуть бэкапнул, параметр Raw Read Error Rate вырос до 63 000+.
А через пару дней сам упал до 40 000+..

Эмм.. Это как понимать ?

[southman]

Raw Read Error Rate вырос до 63 000+.
А через пару дней сам упал до 40 000+..

Эмм.. Это как понимать ?

Это нормально - не все параметры СМАРТ являются накопительными. Если болячка уйдет, он может легко вернутся в ноль сам. В том и особенность, что идеально смотреть картину в динамике.
Вообще, конкретно этот п.01 смотрится в совокупности с остальными, по нему одному ясно, что есть проблема при чтении, которую диск в общем-то и скорректировал.

[Дима Динамит]

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

[H_U_L_K]

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

Вскрытие гермоблока будет дороже, нежели отправить обратно по гарантии.