[Из песочницы] Гальванизация трупа: как удалось оживить битый HDD для хранения чего-нибудь ненужного
Попался мне недавно битый внешний жесткий диск… Ну, как попался? Сам купил по дешевке.Диск как диск: железная коробочка, внутри — USB2SATA контроллер и ноутбучный диск фирмы Samsung на 1 Тб. По описанию продавца выходило, что глючит именно USB-контроллер. Сначала, мол, и пишет, и читает хорошо, а потом постепенно начинает тормозить и вообще отваливается. Явление для внешних дисков без дополнительного питания довольно частое, так что я ему, конечно, поверил. Ну, а что — дешево же.
Итак, радостно разбираю коробочку, достаю оттуда диск и втыкаю в проверенный временем и невзгодами адаптер. Диск включился, завелся, определился, и даже подмонтировался в линуксе. На диске обнаружилась файловая система NTFS и с десяток фильмов. Нет, не про эротические приключения, а совсем даже наоборот: «Левиафаны» всякие. Казалось бы — ура! Но нет, все только начиналось.Просмотр SMART’а показал неутешительную картину: атрибут Raw Read Error Rate упал аж до единицы (при пороге 51), что означает только одно: у диска что-то очень и очень не в порядке с чтением с пластин. Остальные атрибуты, правда, были в пределах разумного, но от этого было не легче.
Попытка отформатировать диск привела к ожидаемому результату: ошибка записи. Можно было, конечно, составить список битых секторов штатной утилитой badblocks, а потом этот список подсунуть при создании файловой системы. Но я эту идею отверг как непрактичную: слишком уж долго пришлось бы ждать результата. Да и, как потом выяснилось, составленный список секторов был бы бесполезен: в поврежденных областях сектора читаются нестабильно, поэтому то, что прочиталось один раз, в следующий раз может выдать ошибку чтения.
Вдоволь наигравшись со всякими утилитами, я выяснил следующие подробности:
Битых секторов много, но расположены они не случайно по всему диску, а плотными группами. Между этими группами имеются довольно обширные области, где чтение и запись идут безо всяких проблем. Попытка исправить битый сектор перезаписью (чтобы контроллер его подменил на резервный) не срабатывает. Иногда после этого сектор читается, иногда нет. Более того, иногда попытка записи в битый сектор приводит к тому, что диск на несколько секунд «отваливается» от системы (видимо, ресетится контроллер самого диска). При чтении ресетов нет, но на попытку прочитать битый сектор уходит полсекунды, а то и больше. «Битые области» довольно стабильны. Так, самая первая из них начинается в районе 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.Конечно, для хранения чего-то важного такое извращение использовать нельзя, но в качестве развлечения может оказаться полезно. Когда вопрос стоит, на магнитики диск разобрать или сначала помучиться, мой ответ: «конечно, помучиться!».
