Как перезаписать очень большой жесткий диск (18 ТБ) случайными данными с помощью команд оболочки в Linux
Я хотел бы перезаписать очень большой жесткий диск (18 ТБ) случайными байтами, чтобы затем проверить интеллектуальные данные на наличие перераспределенных секторов или других ошибок.
Поскольку badblocks имеет некоторые ограничения на количество блоков, с которыми он будет работать за один запуск, я попробовал «метод cryptsetup», описанный в Wiki Archlinux:
https://wiki.archlinux.org/title/Badblocks#Finding_bad_sectors
Я установил зашифрованное поле логического устройства на весь диск, а затем с помощью команды «shred» записал нули в открытое поле устройства:
cryptsetup open /dev/device eld --type plain --cipher aes-xts-plain64
shred -v -n 0 -z /dev/mapper/eld
Далее он печатал такие строки, как
shred: /dev/mapper/eld: pass 1/1 (000000)...870MiB/17TiB 0%
shred: /dev/mapper/eld: pass 1/1 (000000)...1.7GiB/17TiB 0%
...
shred: /dev/mapper/eld: pass 1/1 (000000)...4.1TiB/17TiB 24%
но потом остановилось на написанном 4.1ТиБ/17ТиБ. Я проверил это с помощью шестнадцатеричного дампа, нули не записывались за пределами байтового адреса 0x428249b0000 (4570459340800 ~ 4,156 ТиБ):
hexdump -C --skip 0x428249a0000 /dev/mapper/eld | head
428249a0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
428249b0000 b3 cd d0 34 72 15 f2 2c f6 32 90 fb 69 24 1f ec |...4r..,.2..i$..|
428249b0010 a0 f4 88 a5 56 e7 13 82 94 e5 e0 f5 37 da c3 59 |....V.......7..Y|
428249b0020 9b 55 9f d8 39 a1 41 dc 52 ca 7b 3a 95 f5 59 e2 |.U..9.A.R.{:..Y.|
У многих стандартных команд возникают проблемы с дисками большой емкости, поскольку используемые числа слишком велики для 32-битных типов данных. Какие инструменты чтения/записи в Linux способны надежно читать/записывать за пределами этих воображаемых границ 2 ТиБ,4 ТиБ?
2 ответа
Изменить: Обновлено в соответствии с комментарием.
Я бы просто использовал
dd if=/dev/urandom of=/dev/sdX bs=1M status=progress iflag=fullblock oflag=fullblock
Здесь/dev/sdXэто устройство для жесткого диска.
Вместо cryptsetup + shred я использовал cryptsetup + pv (cat должен работать и вместо pv, но он не будет давать никакой информации о ходе работы) и указал стандартный ввод на /dev/zero:
cryptsetup open /dev/device eld --type plain --cipher aes-xts-plain64
</dev/zero pv >/dev/mapper/eld
Это имеет то преимущество (по сравнению с dd), что не нужно указывать непонятные аргументы, а производительность по каналу SATA 3.3 6 Гбит/с хорошая (>200 МБ/с).
pv все еще не сработал, когда был достигнут конец, но я проверил, что, тем не менее, он перезаписал все логическое устройство нулями. Это означает, что dm-crypt перезаписал весь жесткий диск псевдослучайными байтами.
Теперь ошибки жесткого диска можно проверить как минимум двумя способами:
1. Поиск поврежденных данных SMART (например, перераспределенных секторов) в выходных данных
smartctl -a /dev/device
2. Чтение данных из /dev/mapper/eld и проверка того, что все прочитанные байты имеют нулевое значение. Запуск команды cmp из diffutils для сравнения:
cmp -l -b /dev/zero /dev/mapper/eld
Он либо напечатает байтовый адрес первого несоответствия и завершит работу с ошибкой, либо не обнаружит никакого несоответствия, а затем напечатает «cmp EOF on /dev/mapper/eld ...» (и все равно завершится с ошибкой).
Несоответствие означает, что либо на жестком диске произошел постоянный сбой записи в этой позиции, либо это может быть случайная ошибка, которая не будет повторяться точно в той же позиции.
При первом запуске cmp я действительно получил ошибку уже через 8 секунд, чему очень удивился. Данные SMART не показали какого-либо ухудшения качества, а системный журнал не выявил никаких сообщений об ошибках, касающихся жесткого диска.
Затем я попытался еще раз запустить команду cmp, чтобы проверить, реальна ли ошибка записи, но несоответствие в этой позиции больше не возникло. Это была какая-то случайная ошибка во всем процессе чтения+оценки. Так что не полагайтесь на один запуск команды cmp; в случае обнаружения несоответствия запустите его еще раз. Если ошибка исчезнет, проигнорируйте первое несоответствие или попробуйте еще раз. Если ошибка не устранена, верните жесткий диск продавцу, поскольку он, скорее всего, неисправен, и его деградация со временем может происходить быстрее, чем у исправного жесткого диска.
.