Pull to refresh

Гальванизация трупа: как удалось оживить битый HDD для хранения чего-нибудь ненужного

Reading time 5 min
Views 138K
Попался мне недавно битый внешний жесткий диск… Ну как попался? Сам купил по дешевке.

Диск как диск: железная коробочка, внутри — USB2SATA контроллер и ноутбучный диск фирмы Samsung на 1 Тб.. По описанию продавца выходило, что глючит именно USB-контроллер. Сначала, мол, и пишет, и читает хорошо, а потом постепенно начинает тормозить и вообще отваливается. Явление для внешних дисков без дополнительного питания довольно частое, так что я ему, конечно, поверил. Ну а что — дешево же.

Итак, радостно разбираю коробочку, достаю оттуда диск и втыкаю в проверенный временем и невзгодами адаптер. Диск включился, завелся, определился, и даже подмонтировался в линуксе. На диске обнаружилась файловая система NTFS и с десяток фильмов. Нет, не про эротические приключения, а совсем даже наоборот: «Левиафаны» всякие. Казалось бы — ура! Но нет, все только начиналось.

Просмотр SMART'а показал неутешительную картину: атрибут Raw Read Error Rate упал аж до единицы (при пороге 51), что означает только одно: у диска что-то очень и очень не в порядке с чтением с пластин. Остальные атрибуты, правда, были в пределах разумного, но от этого было не легче.

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

Вдоволь наигравшись со всякими утилитами, я выяснил следующие подробности:
  1. Битых секторов много, но расположены они не случайно по всему диску, а плотными группами. Между этими группами имеются довольно обширные области, где чтение и запись идут безо всяких проблем.
  2. Попытка исправить битый сектор перезаписью (чтобы контроллер его подменил на резервный) не срабатывает. Иногда после этого сектор читается, иногда нет. Более того, иногда попытка записи в битый сектор приводит к тому, что диск на несколько секунд «отваливается» от системы (видимо, ресетится контроллер самого диска). При чтении ресетов нет, но на попытку прочитать битый сектор уходит полсекунды, а то и больше.
  3. «Битые области» довольно стабильны. Так, самая первая из них начинается в районе 45-го гигабайта с начала диска, и тянется довольно далеко (насколько именно, с наскоку выяснить не удалось). Путем проб и ошибок удалось также нащупать начало второй такой области где-то в середине диска.

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

Сказано — сделано. На коленке была написана утилитка, читающая с диска до тех пор, пока не попадется сбойный сектор. После этого утилитка помечала как сбойную (у себя в табличке, естественно) целую область заданной длины. Далее помеченная область пропускалась (чего ее проверять — уже пометили как плохую) и утилита читала сектора дальше. После пары экспериментов было решено помечать сбойной область в 10 мегабайт: это уже достаточно много, чтобы утилитка быстро отработала, но и достаточно мало, чтобы потери дискового пространства стали слишком большими.

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



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

Но ведь у нас уже давно 21-й век, время новых технологий и дисковых массивов! А значит, можно склеить из этих мелких разделов один дисковый массив, создать на нем файловую систему и горя не знать.

По карте битых областей была составлена мега-команда для создания разделов. Я использовал GPT, чтобы не париться по поводу того, какие из них должны быть primary, а какие extended:

# parted -s -a none /dev/sdc unit s mkpart 1 20480 86466560 mkpart 2 102686720 134410240 mkpart 3 151347200 218193920 mkpart 4 235274240 285306880 mkpart 5 302489600 401612800 mkpart 6 418078720 449617920 mkpart 7 466206720 499712000 mkpart 8 516157440 548966400 mkpart 9 565186560 671539200 mkpart 10 687595520 824811520 mkpart 11 840089600 900280320 mkpart 12 915640320 976035840 mkpart 13 991354880 1078026240 mkpart 14 1092689920 1190871040 mkpart 15 1205288960 1353093120 mkpart 16 1366794240 1419919360 mkpart 17 1433600000 1485148160 mkpart 18 1497927680 1585192960 mkpart 19 1597624320 1620684800 mkpart 20 1632808960 1757368320 mkpart 21 1768263680 1790054400 mkpart 22 1800908800 1862307840 mkpart 23 1872199680 1927905280 mkpart 24 1937203200 1953504688


Команда работала довольно долго (несколько минут). Итого получилось 24(!) раздела, каждый своего размера.

Разделы
# parted /dev/sdc print
Model: SAMSUNG HM100UI (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      10.5MB  44.3GB  44.3GB               1
 2      52.6GB  68.8GB  16.2GB               2
 3      77.5GB  112GB   34.2GB               3
 4      120GB   146GB   25.6GB               4
 5      155GB   206GB   50.8GB               5
 6      214GB   230GB   16.1GB               6
 7      239GB   256GB   17.2GB               7
 8      264GB   281GB   16.8GB               8
 9      289GB   344GB   54.5GB               9
10      352GB   422GB   70.3GB               10
11      430GB   461GB   30.8GB               11
12      469GB   500GB   30.9GB               12
13      508GB   552GB   44.4GB               13
14      559GB   610GB   50.3GB               14
15      617GB   693GB   75.7GB               15
16      700GB   727GB   27.2GB               16
17      734GB   760GB   26.4GB               17
18      767GB   812GB   44.7GB               18
19      818GB   830GB   11.8GB               19
20      836GB   900GB   63.8GB               20
21      905GB   917GB   11.2GB               21
22      922GB   954GB   31.4GB               22
23      959GB   987GB   28.5GB               23
24      992GB   1000GB  8346MB               24



Следующий шаг — слепить из них единый диск. Перфекционист внутри меня подсказывал, что наиболее правильно было бы замутить какой-нибудь RAID6-массив, устойчивый к отказам. Практик же возражал, что все равно выпавший в астрал раздел будет нечем заменить, так что сойдет и обычный JBOD — чего пространство-то зазря терять? Практик победил:

# mdadm --create /dev/md0 --chunk=16 --level=linear --raid-devices=24 /dev/sdc1 /dev/sdc2 /dev/sdc3 /dev/sdc4 /dev/sdc5 /dev/sdc6 /dev/sdc7 /dev/sdc8 /dev/sdc9 /dev/sdc10 /dev/sdc11 /dev/sdc12 /dev/sdc13 /dev/sdc14 /dev/sdc15 /dev/sdc16 /dev/sdc17 /dev/sdc18 /dev/sdc19 /dev/sdc20 /dev/sdc21 /dev/sdc22 /dev/sdc23 /dev/sdc24

Ну вот и все. Осталось создать файловую систему и смонтировать оживший диск:

# mkfs.ext2 -m 0 /dev/md0
# mount /dev/md0 /mnt/ext

Диск получился довольно вместительным, 763 гигабайта (т. е. удалось использовать 83% емкости диска). Другими словами, «в отвал» ушло всего 17% от первоначального терабайта:

$ df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                  9.2G  5.6G  3.2G  64% /
...
/dev/md0                                                763G  101G  662G  14% /mnt/ext

Тестовый набор мусорных фильмов залился на диск без ошибок. Правда, скорость записи была небольшой и плавала от 6 до 25 мегабайт в секунду. Чтение же было стабильным, со скоростью 25-30 мб/сек, то есть ограничивалась адаптером, подключенным в USB 2.0.

Конечно, для хранения чего-то важного такое извращение использовать нельзя, но в качестве развлечения может оказаться полезно. Когда вопрос стоит, на магнитики диск разобрать или сначала помучиться, мой ответ: «конечно, помучиться!».

Напоследок — ссылка на репозиторию с утилитой: github.com/dishather/showbadblocks
Tags:
Hubs:
+55
Comments 79
Comments Comments 79

Articles