Представьте: диск исправен, SMART ничего подозрительного не показывает, но чтение определённого сектора внезапно возвращает
Input/output error.В Linux такое можно воспроизвести специально. Для этого есть
dm-dust - target Device Mapper, который имитирует повреждённые блоки и позволяет проверить, как файловая система или приложение переживёт ошибку чтения.1️⃣Создаём тестовый диск
Чтобы не рисковать настоящим накопителем, используем файл и loop-устройство:
truncate -s 64M /tmp/dust.img
LOOP=$(sudo losetup --find --show /tmp/dust.img)
SECTORS=$(sudo blockdev --getsz "$LOOP")
echo "0 $SECTORS dust $LOOP 0 512" |
sudo dmsetup create dusttest
Теперь
/dev/mapper/dusttest выглядит как обычное блочное устройство. Пока все операции проходят без искусственных ошибок.2️⃣ Ломаем конкретный блок
Допустим, хотим сделать нечитаемым блок №64:
sudo dmsetup message dusttest 0 addbadblock 64
sudo dmsetup message dusttest 0 enable
Пробуем прочитать его напрямую:
sudo dd if=/dev/mapper/dusttest \
of=/dev/null bs=512 count=1 skip=64 \
iflag=direct
Вместо данных получим:
dd: error reading '/dev/mapper/dusttest':
Input/output error
Причём ошибка возникает в Device Mapper. Сам backing storage остаётся исправным.
3️⃣ Проверяем восстановление
У
dm-dust есть интересная особенность: запись в повреждённый блок проходит успешно и удаляет его из списка bad blocks.Так имитируется поведение диска, который переназначил проблемный сектор.
Для проверки файловой системы можно сначала создать её на
/dev/mapper/dusttest, записать тестовые файлы, а затем включить ошибки на выбранных блоках данных или метаданных.Дальше смотрим:
sudo dmesg -w
sudo dmsetup status dusttest
Интересно, вернёт ли приложение
EIO, продолжит ли файловая система работать и не перейдёт ли она в read-only режим. Конкретная реакция зависит от файловой системы и того, какой блок оказался недоступен.После эксперимента:
sudo dmsetup message dusttest 0 disable
sudo dmsetup message dusttest 0 clearbadblocks
sudo dmsetup remove dusttest
sudo losetup -d "$LOOP"