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

[rapid]

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

вы ж понимаете, что на слух все очень субъективно...
вот ТУТ можно послушать, что и как звучит на самом деле....

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

про такого родо случаи более подробно можно прочитать тут:
http://www.chip-center.dn.ua/vosstanovleni...acii-v-donetske
читать, начиная со слов "Многие пользователи пытаются сами пробовать восстановить потерянную информацию."

Мини FAQ по HDD


===
В общем винт периодически на несколько секунд перестает работать типо щелчок и останавливается но сразу же запускается при этом виндовс зависает и приходится перезагружаться(( Вот сижу и думаю что делать брать новый или можно что то сделать с этим)

[Allex]

я ситаю пробоему редкой и таки считаю проблемой железа иначе на всех дисках одной партии эта проблема должна проявиться

С чего бы?.. У нас большинство ставят свякие "сборки", у которых "расширенная диагностика" отключена по умолчанию, так что и проблем возникнуть просто не с чего.

и производитель будет менять софт для сдержания возвратов

Ото ему не хватало... ;+))

а не прикалываться с урезнием размера

Ой. Вообще-то Over-Provisioning - это штатная операция, рекомендуемая производителями для высоконагруженных SSD...

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

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

Опять же, "резерв" - это не физически выделенное пространство, это _количество_ постоянно оборачивающихся исправных блоков, которое оставлено для того, чтобы контроллеру было куда тасовать страницы при сборке мусора.

[Datarecover]

!Вычислить чип" - на самом деле не просто, а очень просто. Запускаешь Flash ID для соответствующего контроллера - и он тебе выдаст всю карту битых блоков.

если не сложно то хотелось бы поподробней , а то я по используя flash id получаю только id микросхем. Возможно я в чем то отстал илb что то пропустил. Просто в моем понимании чтобы получить список блоков нужно вычитать и распарсить таблицы трансляции. И для этого нужно чуть больше чем утилиту для конкретного чипа. А часто нужны утилиты для конкретного семейства дисков. Но я надесь , что ошибаюсь и все намного проще.

P.S. А вообще - о каком SSD речь? Что за контроллер, что за флеш?

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

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


Опять же, "резерв" - это не физически выделенное пространство, это _количество_ постоянно оборачивающихся исправных блоков, которое оставлено для того, чтобы контроллеру было куда тасовать страницы при сборке мусора.

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

[Allex]

если не сложно то хотелось бы поподробней , а то я по используя flash id получаю только id микросхем. Возможно я в чем то отстал илb что то пропустил. Просто в моем понимании чтобы получить список блоков нужно вычитать и распарсить таблицы трансляции. И для этого нужно чуть больше чем утилиту для конкретного чипа. А часто нужны утилиты для конкретного семейства дисков. Но я надесь , что ошибаюсь и все намного проще.

Намного проще.

Вот тебе вывод phison_flash_id:

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

v0.33a
OS: 10.0 build 19042
Drive: 2(NVME)
Driver : W10(2:3)
Model : SPCC M.2 PCIe SSD
Fw : ECFM32.1
Size : 244198 MB [256.1 GB]
LBA Size: 512
Read_System_Info_5008 error: -1
Firmware lock supported [02 01] [P004] [0100]
Drive unlocked [02 03]
F/W : ECFM32.1 00
P/N : 511-210113202
Bank00: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank01: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank02: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank03: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank04: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank05: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank06: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank07: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Controller : PS5012-E12 [PS5012AA]
CPU Clk : 666
Flash CE : 8
Flash Channel : 8
Interleave : 1
Flash CE Mask : [++++++++ -------- -------- --------]
FlashR Clk,MT : 666
FlashW Clk,MT : 666
Block per CE : 2012
Page per Block: 1152
Bit Per Cell : 3(TLC)
DRAM Size,MB : 256
DRAM Clock,MHz: 1600
DRAM Type : DDR3
PMIC Type : PS6102/PS6106
PE Cycle Limit: 3000
ONFI : YMTC YMN08TE1W00C3B (2020-44) [DE12]
Page size : 18432 (16384+2048)
Page/Block: 1152
Block/LUN : 2012
LUN/Chip : 1
Bit/Cell : 3 (TLC)
Endurance : 3000
PlanAdrBit: 1 (2 plane)


Defects Early Read Prog Erase
Bank00: 7 0 0 0
Bank01: 7 0 0 0
Bank02: 4 0 0 0
Bank03: 6 0 0 0
Bank04: 16 0 0 0
Bank05: 16 0 0 0
Bank06: 6 0 0 0
Bank07: 6 0 0 0
Total : 68 0 0 0

Defects Early Read Prog Erase
Ce00Pl0: 3 0 0 0
Ce00Pl1: 4 0 0 0
Ce01Pl0: 3 0 0 0
Ce01Pl1: 4 0 0 0
Ce02Pl0: 2 0 0 0
Ce02Pl1: 2 0 0 0
Ce03Pl0: 4 0 0 0
Ce03Pl1: 2 0 0 0
Ce04Pl0: 10 0 0 0
Ce04Pl1: 6 0 0 0
Ce05Pl0: 13 0 0 0
Ce05Pl1: 3 0 0 0
Ce06Pl0: 4 0 0 0
Ce06Pl1: 2 0 0 0
Ce07Pl0: 3 0 0 0
Ce07Pl1: 3 0 0 0
Total : 68 0 0 0

Последние блоки - это как раз перечисление дефектных блоков.

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

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

Теперь - "долгое чтение". Оно бывает по двум причинам: утекший заряд в ячейках (дрянная память, или изношенная память, или долгое хранение при повышенной температуре, или активное чтение одного и того же места или комбинация перечисленного) - тогда флеш многократно читает страницу в надежде, что в какой-то из разов она прочитается так, что алгоритмы восстановления данных сумеют восстановить исходное ее содержимое, или - многократное обращение к всему массиву флеша с тем, чтобы найти нужную страницу ("безбуферный SSD", замученный транслятор). Что характерно - SE помогает при немедленной проверке чтения в обоих случаях: так как после SE читать из флеша ничего не нужно - то контроллер на запросы отплевывается нулями сразу же, с максимальной скоростью. Потому - чтобы понять, какой из этих двух вариантов имеет место быть, стоит после SE линейно прописать весь накопитель ненулевым паттерном (хотя бы тот же тест записи поверхности у AIDA), и дать ему полежать хоть несколько дней (если есть возможность положить в тепло - это будет еще надежнее). Если после такого выдерживания на графике чтения AIDA окажутся глубокие провалы (неглубокие - не в счет, они могут аозникнуть по массе причин, например, при переписывании данных из SLC буфера в постоянное хранилище) - то скорее всего дело в флеше. Если же график чтения получится более или менее ровным - дело было в трансляторе.

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

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

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

Не встречал я пока такой стадии в SSD. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

По поводу параметров где они содержаться в заголвке страницы ?

А вот это - уж как в прошивке прописано. Страница, кстати, здесь ни при чем - это параметры блока стирания, а не отдельной страницы. А вот где их хранить - возможны варианты. Это может быть как отдельная таблица, так и использование какого-нибудь блока избыточных битов самого блока стирания... Первый вариант удобнее для организации поиска наиболее/наименее заезженных блоков, второй - для обеспечения надежности привязки счетчиков к конкретному блоку. Ну и комбинацией из обоих способов тоже вполне можно воспользоваться.... ;+))

[Datarecover]

Намного проще.

Вот тебе вывод phison_flash_id:

да спасибо. Просто те утилиты что попадальсь раньше, полезными для восстановления не были и я пеерстал им уделять внимание. Да и в основном в доступе были утилиты тоько для UFD. А для починки дисков приходилось разбирать фирмварь.

Теперь - "долгое чтение". Оно бывает по двум причинам: утекший заряд в ячейках (дрянная память, или изношенная память, или долгое хранение при повышенной температуре, или активное чтение одного и того же места или комбинация перечисленного) - тогда флеш многократно читает страницу в надежде, что в какой-то из разов она прочитается так, что алгоритмы восстановления данных сумеют восстановить исходное ее содержимое, или - многократное обращение к всему массиву флеша с тем, чтобы найти нужную страницу ("безбуферный SSD", замученный транслятор). Что характерно - SE помогает при немедленной проверке чтения в обоих случаях: так как после SE читать из флеша ничего не нужно - то контроллер на запросы отплевывается нулями сразу же, с максимальной скоростью. Потому - чтобы понять, какой из этих двух вариантов имеет место быть, стоит после SE линейно прописать весь накопитель ненулевым паттерном (хотя бы тот же тест записи поверхности у AIDA), и дать ему полежать хоть несколько дней (если есть возможность положить в тепло - это будет еще надежнее). Если после такого выдерживания на графике чтения AIDA окажутся глубокие провалы (неглубокие - не в счет, они могут возникнуть по массе причин, например, при переписывании данных из SLC буфера в постоянное хранилище) - то скорее всего дело в флеше. Если же график чтения получится более или менее ровным - дело было в трансляторе.

полностью с этим согласен, и в общем именно исходя из похожей схемы я и делал выводы что проблема с чипами и как показывала практика иногда хватало просто пропаять чипы и это помогало , в принципе поэтому я и утверждаю что проблема в железе. И сейчас пропись патернами используется всеми около професиональными тулзами еще с моментов определения алгоритмов кодировния, а последние время это стало важно и для ХДД. И именно по этот алгритм я писал что определить чип не возможно. Хотя среднестатистический пользователь наверно не будет и паять чип. И спасибо за рекомендации аиды , а то я в основном людям совету всякие патерн райтеры или ртестер (со своими тестами) ну или на крайняк дисканализкр от которых пользователи пугаються и не доверяют их результатам.

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

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

Не встречал я пока такой стадии в SSD. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

ну так это и есть стадия заполнения Г листа , но она наступает для блоков которые ПОМЕЧЕНЫ для стирания, основной процес их не стирает а помечает. а пост процес стираетю На хдд это чуть иначе там основной процес осуществляет записи и\или чтение (для сигейта) и если сектор выщел за пределы по времени он уходит в пендинг лист и тем самым покинул зону трансляции , затем во время постпроцесса на него даеться несколько проверок и он помещаеться в Г-лист либо возвращается в резерв. ССД тоже используют основной поток работы и вторичный и основной поток не стирает данные а стираються они в доп потоке который я и назвала стадией принятия решений, ну пусть будет процесом стирания. Но в софте начинается гонка за ресурсами на уровне таблицы блоков помеченных для удаления , я понимаю что это можно расписать еще более подробно поключивши туда трим и шурфинг , но это работа штатная и она одинаково работает на одинаковой прошивке. Я иногда подбирал случайную запись при котрой эти тормоза становились заметны, хотя они уже проявляються на стадии выхода за пределы буфера, но не видел перманентного торможения (хотя наверно попробую создать такой тест) поэтому и относил это все к железу.

И еще, мне в основном уже доходят диски с явными проблемами, тк их уже часто смотрели ля меня , может по этому те что лечаться копированием просто не доходят.

[Allex]

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

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

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

[Datarecover]

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

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

я и писал , что в ССД нет пендингов. В них эту фукцию выполняет список помеченных на стирание. И поэтому они тоже могут быть подвержены своеобразному пендинг багу и именно его и лечат стиранием. Но я сейчас посмотрел базу и выяснил , что ни из затертых у меня не прожил дольше нескольких месяцев. Хотя часть их них уже не определялась при поступлении ко мне , и были починены софтово , обновление софта пересчет транслятора с сертификацией. А для тех что определялись просто SE.

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

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

я и писал , что в ССД нет пендингов. В них эту фукцию выполняет список помеченных на стирание. И поэтому они тоже могут быть подвержены своеобразному пенлинг багу и именно его и лечат стиранием. Но я сейчас посмотрел базу и выяснил , что ни из затертых у меня не прожил дольше нескольких месяцев. Хотя часть их них уже не определялась при посткплении ко мне , и были починены софтово , обновление софта пересчет транслятора с сертификацией. А для тех что определялись просто SE.
Да и поэтому часто приходиться нагревать чип при вычитке , но в моем случае я проверил диск когда он уже остыл. И в отличие от софтово чиненных работает уже несколько лет в нотике.

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

Сообщение отредактировал Datarecover - Apr 23 2021, 14:01

[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]

ㅤ

Сообщение отредактировал KoNoRIMCI - Nov 4 2025, 16:14

[Maxxximus]

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

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

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

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

[KoNoRIMCI]

ㅤ

Сообщение отредактировал KoNoRIMCI - Nov 4 2025, 16:14