LINUX.ORG.RU

EVO870, «187 Reported_Uncorrect» и обнуление

 870evo, , , ,


1

4

Стал у меня в начале (склероз: не этого, прошлого) года сбоить EVO870 на терабайт. Заметил по периодическим сбоям на ровном месте, оказывается — ошибки чтения. На нём была только сама ОС и игры, так что заменил без особых потерь. Симптомы простые — в нескольких местах на диске обнаружились локации, откуда ничего не читалось без ошибки. Т.е. никаких этих вот «ssd сбоит, но даёт прочитать хотя бы» — нет, тупо битые файлы, копирование виснет, а «187 Reported_Uncorrect» растёт как на дрожжах. Часть этих зон пришлась на файлы с играми, а некоторые на содержимое /usr. Но поскольку ничего ключевого затронуто не было, то я долго думал, что просто Steam лажает, например.

Если посмотреть SMART, то было примерно так:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9136
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1995
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       3
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       14609
190 Airflow_Temperature_Cel 0x0032   064   055   000    Old_age   Always       -       36
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       14609
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       9
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       4293672984


А потом собстсвенно логи последних из этих 14609 ошибок. Примерно так (если что, здесь и выше значения уже после моих сегодняшних экспериментов, на момент начала было где-то 13 тыщ):
Error 14609 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 90 69 47 40

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  e1 00 0f 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ef 03 46 00 00 00 40 00      01:22:44.593  SET FEATURES [Set transfer mode]
  ef 02 00 00 00 00 40 00      01:22:44.593  SET FEATURES [Enable write cache]
  e1 00 02 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ec 00 01 00 00 00 40 00      01:22:44.593  IDENTIFY DEVICE

Error 14608 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 01 10 00 00 00  Error:  at LBA = 0x00000010 = 16

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 00 90 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 88 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 80 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 78 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 70 69 47 00 00      01:22:44.005  READ FPDMA QUEUED

Error 14607 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 08 00 6a 47 40  Error:  at LBA = 0x00476a00 = 4680192

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 00 00 69 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 08 00 68 47 40 01      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 67 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 66 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 65 47 40 00      01:22:11.833  READ FPDMA QUEUED


Погуглил я тогда интернеты, и нашёл, что на серию 870EVO есть жалобы по всему развитому миру. То ли кремний самсунгу завезли грязный, то ли чихнул кто в стерильной зоне, но чипы памяти вышли сбойные, и SSD стали отказывать по моему сценарию.

Ну я его на полочку положил, да и как-то забыл, благо гарантия до 2026. Вдруг что ещё придумаю. Ну вот сегодня решил придумать. Подключил его, стал делать смарт-тесты. И длинный, и короткий завершались досрочно с ошибкой чтения:

Self-test execution status:      ( 121)	The previous self-test completed having
					the read element of the test failed.

...

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       80%      9137         10544288
# 2  Extended offline    Completed: read failure       90%      9137         10544288
# 3  Extended offline    Completed: read failure       90%      9136         10544288
# 4  Short offline       Completed: read failure       80%      9136         10544288
# 5  Short offline       Completed: read failure       80%      9136         10544288


Стал смотреть badblocks. Он довольно резво начал выплёвывать номера:
smacker@Ideapad510 ~ $ sudo badblocks -v /dev/sdc
Checking blocks 0 to 976762583
Checking for bad blocks (read-only test): 5272132
5272144
5272145
5272146
5272147
5274296
5274297
5274298
5274299
5274516
5274517
5274518
5274519
5276096
5276097
5276098
5276099
5279436
...

Ну я попробовал «полечить» через hdparm (hdparm --repair-sector 5272144 --yes-i-know-what-i-am-doing /dev/sdc), не преуспел. Он снова стал всплывать. Всё это время значение в поле 187 SMART только росло.

Ну тут я психанул и забил диск терабайтом нулей с помощью dd. И что же? А рост закончился. Я запустил badblocks... и он прошелестел всем диском, и ничего не нашёл. Я запустил тест SMART... и он тоже завершился удачно:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9139         -
# 2  Short offline       Completed without error       00%      9138         -
# 3  Short offline       Completed: read failure       80%      9137         10544288
# 4  Short offline       Completed: read failure       80%      9137         10544288
# 5  Extended offline    Completed: read failure       90%      9137         10544288
# 6  Extended offline    Completed: read failure       90%      9136         10544288
# 7  Short offline       Completed: read failure       80%      9136         10544288
# 8  Short offline       Completed: read failure       80%      9136         10544288


Сейчас статистика застыла на таких значениях:
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9139
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1996
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       15972
190 Airflow_Temperature_Cel 0x0032   070   047   000    Old_age   Always       -       30
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       15972
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       10
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       6251131313


И вроде бы больше ничего не происходит (например, поле 187 не изменилось уже после прохода badblocks по всему диску).

А теперь, уважаемые знатоки — внимание, вопрос: диск выздоровел (перемапил сбойные области, я уж не знаю, т.к. «5 Reallocated_Sector_Ct» застыл на 606), или ему временно полегчало напоследок, чтобы он мог позвать близких к смертному одру?

★★★★★

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

Из того, что я в январе-феврале почитал, следовало, что сбоит не модель диска в целом, а именно экземпляры из нескольких серий (870 и ещё, кажется, 970), изготовленные в конкретном месте и конкретный период времени (который, впрочем, можно было оценить только умозрительно) из посредственных компонентов. Т.е. какой конкретно попадётся — фиг его знает.

Smacker ★★★★★
() автор топика

Вряд ли дефектная NAND может чудом выздороветь. Но не вижу проблемы использовать под какие-то данные в единственном экземпляре, которые не жалко потерять. Загрузки, торренты, такие вещи.

anonymous
()

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

А кстати, что там сейчас с гарантией, как она сейчас работает в России?

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

Про гарантию не знаю. Думаю, вернут деньги, и всё. А может и не вернут. Собственно, поэтому я и не побежал сразу в магазин сдавать обратно.

Странно, что обнуление, которое вроде как должно было запустить процесс ремапинга битых секторов (раз уж те же попытки стима по-отдельности перезаписать файлы после провала проверки целостности ни к чему не приводили), никак не отразилось в смарте. Я бы ожидал увеличения числа переопределённых секторов, а их так и осталось в 5 строке 606.

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

Я бы ожидал увеличения числа переопределённых секторов, а их так и осталось в 5 строке 606.

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

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

Ну тут есть вопрос — как минимум в случае с играми из Steam, файлы которых попали на битые сектора, множество попыток перезаписи предпринимались и ранее. Львиная доля изначальных 13k ошибок — это результат работы именно стима. Т.е. стим с упорством, достойным лучшего применения, пытался восстановить, скажем, файлы от L4D2, но это не триггерило ремаппинг сектора. А запись туда же нулей — запустило процесс.

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

Вот я тоже, кстати, приготовился к этому шагу (как и к упомянутому ранее повторному долгому тесту). Скачал исошку Samsung_SSD_870_EVO_SVT02B6Q_Win.iso.

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

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

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

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

Данные сохранились, но сектора которые успели пометиться как Runtime_Bad_Block в таком состоянии и остались (360 штук). Reported_Uncorrect тоже остался в таком-же состоянии (72645).

Собственно вся smart info осталась в том-же состоянии. Но ошибки перестали появляться.

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

О, надо будет глянуть, что у меня, но думаю, что у меня уже другая прошивка, не подверженная проблеме, потому что, как я выше сказал, брал летом в пока еще этом году :)

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

Вот я тоже, кстати, приготовился к этому шагу (как и к упомянутому ранее повторному долгому тесту). Скачал исошку Samsung_SSD_870_EVO_SVT02B6Q_Win.iso.

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

Dimez ★★★★★
()

внимание, вопрос

Runtime_Bad_Block 0x0013 045 045 010 Pre-fail Always - 606

Диск всё. У меня таким образом кингсотон повредил часть фс. Правда у меня всего 1 такой бэд блок. Имхо, дальше этот диск только на игрушки.

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

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

А я как раз перепрошил. Только что собрал ноут обратно. Вроде жив, курилка. Опять же, что значит «основательно сыпаться»? Вот у red75prim счёт ошибок дошёл до 72645, а у меня только 15972. Опять же, это же не уникальные ошибки, а число раз, когда в принципе доходило до сбойных секторов — по многу раз до каждого.

Мои соболезнования. Обновлённую прошивку SVT02B6Q выложили 2.5 года назад…

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

Я, кстати, со временем укладывания на полку ошибся, это не в этом году было, а в прошлом. Я другой SSD купил 7 марта 2023. Стало быть, тот лежит на полке как минимум с этого момента, а вообще может и раньше, т.к. я вроде бы в промежутке сидел на подменном небольшой ёмкости. Блин, стар стал, не помню уже нифига.

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

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

Диск всё. У меня таким образом кингсотон повредил часть фс. Правда у меня всего 1 такой бэд блок.

Так ведь дело-то в том, где этот блок. У меня как-то на винче хитачи похерился целиком раздел с XFS, без возможности восстановления — просто у шлейфа контакт отошёл во время работы. А потом этот же винч работал годами (да и сейчас где-то лежит, вполне рабочий, только ненужный).

Имхо, дальше этот диск только на игрушки.

Но так ведь не только
Runtime_Bad_Block 0x0013 045 045 010 Pre-fail Always - 606
но и
Reallocated_Sector_Ct 0x0033 045 045 010 Pre-fail Always - 606

Т.е. вроде как все битые были заменены резервом. Нет?

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

Ну так и что плохого? 606 секторов по 512 байт это 303 килобайта всего. На терабайтнике должно быть гораздо больше резервного места. Опять же, вопрос в происхождении этих битых секторов и носит ли повреждение (если это оно, а не какой-то рабочий сбой) ползучий характер.

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

В моём случае - продолжил сыпаться.

Model Family:     Kingston SSDNow UV400/500
Device Model:     KINGSTON SUV500MS240G

...

183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       3

Изначально, когда я его забраковал, там был всего 1. Потом я его поставил как ссд для игр в стиме. Теперь тут уже 3.

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

Насколько я понимаю, выход блоков из строя — для ssd нормально, пока это может компенсироваться резервными блоками. Опять же, на некоторых ssd (не самсунг, а transcend, например) прямо в smart есть поле «Initial_Bad_Block_Count», т.е. «бэды с завода», которые нашли и заблэклистили при тестировании только что собранного девайса. И ничего.

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

Насколько я понимаю, выход блоков из строя — для ssd нормально

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

Initial_Bad_Block_Count

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

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

а не чтоб они всплывали во время работы устройства.

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

Smacker ★★★★★
() автор топика

Погуглил я тогда интернеты, и нашёл, что на серию 870EVO есть жалобы по всему развитому миру. То ли кремний самсунгу завезли грязный, то ли чихнул кто в стерильной зоне, но чипы памяти вышли сбойные, и SSD стали отказывать по моему сценарию.

Нет, это вроде глючная прошивка. Давно надо было обновить

Ну тут я психанул и забил диск терабайтом нулей с помощью dd

Ну, как вариант. Не забудь потом ещё сделать fstrim или (опасно, уничтожит данные, применять только на пустом разделе) blkdiscard

И это, прошивку блин обнови

диск выздоровел (перемапил сбойные области, я уж не знаю, т.к. «5 Reallocated_Sector_Ct» застыл на 606), или ему временно полегчало напоследок,

ИМХО, ни то, ни другое. Ячейки продолжают терять заряд (как и на любом ssd), старая глючная прошивка это игнорирует и не обновляет запись при необходимости. Через какое-то время ты получишь то же самое

Для ssd/nvme есть набор общих рекомендаций

  • обнови прошивку. ну или хотя бы посмотри, есть ли новая и что про неё пишут
  • на новом диске сделай blkdiscard (сообщить контроллеру, что все блоки свободные) и после этого при разметке оставь какую-то часть (5..10%) диска неиспользуемой. Т.е. диск 930 GiB, партицию создаёшь на 860 GiB, остаток контролер ssd будет использовать для балансировки нагрузки
router ★★★★★
()
Ответ на: комментарий от router

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

router ★★★★★
()

Это прошивка с багом. Примерно через год старые данные начинают считываться с ошибками. После этого блок с ошибкой чтения помечается как сбойный. Скорее всего процедура регенерации не запускалась вовремя. В новой прошивке это исправили. Решение для сбойного диска - полная очистка диска утилитой blkdiscard (TRIM), далее обновление прошивки. Если пытаться сделать копию диска, и сбойных блоков там будет много, то диск перейдёт в RO, после чего его можно только выкинуть.

m0xf
()

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

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

Итого: опять разобрал ноутбук (через usb - sata кабель blkdiscard не работает), сделал blkdiscard. Сделал долгий тест. Он, правда, заснул при первой попытке и тест отменил, пришлось по второму кругу делать и параллельно дёргать через watch, чтоб не заснул.

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      9141         -
# 2  Extended offline    Aborted by host               80%      9140         -
# 3  Short offline       Completed without error       00%      9139         -
# 4  Short offline       Completed without error       00%      9138         -
# 5  Short offline       Completed: read failure       80%      9137         10544288
# 6  Short offline       Completed: read failure       80%      9137         10544288
# 7  Extended offline    Completed: read failure       90%      9137         10544288
# 8  Extended offline    Completed: read failure       90%      9136         10544288
# 9  Short offline       Completed: read failure       80%      9136         10544288
#10  Short offline       Completed: read failure       80%      9136         10544288


Итого остановились на вот таких цифрах:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9147
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       2010
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       15972
190 Airflow_Temperature_Cel 0x0032   070   047   000    Old_age   Always       -       30
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       15972
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       12
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       6251131313
252 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0


Опять же, прошивка текущая.

Firmware Version: SVT02B6Q
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Size:      512 bytes logical/physical

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

В сухом остатке: из лишнего — видимо, зря я его нулями забил. Съел 1/600 ресурса TBW, или 0.16%. С другой стороны, если бы он не лежал на полке больше года, а работал бы, то и так бы съел примерно столько же. Шило обменяно на мыло. Год отработал на старой прошивке, полагая, что дело в чипах памяти. Это всё зря было. Надо было сразу идти на лор жаловаться на жизнь.

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

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

В ссд физические блоки гораздо больше 512 байт. Что-то вроде 1-2 мегабайт

Badblocks показал, что они там кластерами идут по много штук подряд. Так что я полагаю, что даже в случае выхода из строя сразу кусками по 1-2 мегабайта, общие потери не должны быть такие уж большие — скорее всего, эти кластеры сбоев и приходятся на один блок.

Кстати, в выводе badblocks они идут группами по 4 штуки (см выше). Так что более низкий уровень, видимо, организован сегментами по 2 кб.

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