Оцинковка Трупа: Как Нам Удалось Оживить Сломанный Hdd Для Хранения Чего-То Ненужного

Недавно наткнулся на сломанный внешний жесткий диск.

Ну и как я это понял? Я купил его себе по дешевке.

Диск как диск: железная коробка, внутри контроллер USB2SATA и Диск для ноутбука Samsung емкостью 1 ТБ.

По описанию продавца оказалось, что глючил именно USB-контроллер.

Поначалу, говорят, он хорошо пишет и читает, но потом постепенно начинает тормозить и вообще отваливается.

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

Ну и что - это дешево.

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

Диск включился, запустился, определился и даже смонтировался в Linux. На диске была файловая система NTFS и дюжина фильмов.

Нет, не об эротических приключениях, а как раз наоборот: «Левиафаны» бывают всякие.

Казалось бы – ура! Но нет, все только начиналось.

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

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

Попытка отформатировать диск дала ожидаемый результат: ошибка записи.

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

Но я отверг эту идею как непрактичную: слишком долго ждать результата.

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

Наигравшись всякими утилитами, я выяснил следующие подробности:

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

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

Естественно, для этого сначала нужно выяснить границы «хороших» и «плохих» участков.

Сказано - сделано.

На коленке была написана утилита, которая читает с диска до тех пор, пока не встретит битый сектор.

После этого утилита пометила как неисправную (в своей табличке, конечно) всю область заданной длины.

Потом отмеченная область пропускалась (зачем ее проверять - она и так помечена как плохая) и утилита читала сектора дальше.

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

Для наглядности результат работы записывался в виде картинки: белые точки — хорошие сектора, красные — плохие сектора, серые — плохая область вокруг плохих секторов.

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

Вот она, эта картинка:

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

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

Кажется, жалко терять столько места, но создавать десятки мелких разделов не хочется.

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

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

Я использовал GPT, чтобы не беспокоиться о том, какой из них должен быть основным, а какой — расширенным:

   

 # 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 Теги: #*nix #Хранилище данных #Восстановление данных #жесткие диски #плохие сектора #RAID JBOD #разделы с пробелами