Как перезаписать очень большой жесткий диск (18 ТБ) случайными данными с помощью команд оболочки в Linux

Я хотел бы перезаписать очень большой жесткий диск (18 ТБ) случайными байтами, чтобы затем проверить смарт-данные на наличие перераспределенных секторов или других ошибок.

Поскольку у badblocks есть некоторые ограничения на количество блоков, с которыми он будет работать за один запуск, я попробовал «метод cryptsetup», описанный в вики archlinux:

https://wiki.archlinux.org/title/Badblocks#Finding_bad_sectors

Я установил зашифрованное поле логического устройства на весь диск, а затем использовал команду «shred», чтобы записать нули в открытое поле устройства:

cryptsetup открыть поле /dev/device --type plain --cipher aes-xts-plain64
клочок -v -n 0 -z /dev/mapper/field

Он продолжал печатать такие строки, как

шред: /dev/mapper/eld: пройти 1/1 (000000)...870МиБ/17ТиБ 0%
шред: /dev/mapper/eld: пройти 1/1 (000000)...1,7ГиБ/17ТиБ 0%
...
шред: /dev/mapper/eld: пройти 1/1 (000000)...4.1TiB/17TiB 24%

но потом он остановился на написанном 4.1TiB/17TiB. Я проверил это с помощью шестнадцатеричного дампа, нули не записывались за адресом байта 0x428249b0000 (4570459340800 ~ 4,156 ТиБ):

hexdump -C --skip 0x428249a0000 /dev/mapper/eld | главный
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 могут надежно читать/писать за пределами этих воображаемых границ 2TiB, 4TiB?

Изменить: обновлено в соответствии с комментарием

я бы просто использовал

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress iflag=fullblock oflag=fullblock

Здесь /dev/sdX это устройство для жесткого диска.

Вместо cryptsetup + shred я использовал cryptsetup + pv (cat тоже должен работать вместо pv, но он не будет давать никакой информации о прогрессе) и указал stdin на /dev/zero:

cryptsetup открыть поле /dev/device --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/устройство

2. Чтение данных из /dev/mapper/eld и проверка того, что все прочитанные байты имеют нулевое значение. Запуск команды cmp из diffutils для сравнения:

cmp -l -b /dev/zero /dev/mapper/field

Он либо напечатает байтовый адрес первого несоответствия и выйдет с ошибкой, либо не найдет никакого несоответствия, а затем напечатает «cmp EOF on /dev/mapper/eld…» (и все равно выйдет с ошибкой).

Несоответствие означает, что либо на жестком диске произошел постоянный сбой записи в этой позиции, либо это может быть случайная ошибка, которая не будет повторяться точно в той же позиции.

При первом запуске cmp я действительно получил ошибку уже через 8 секунд, чему очень удивился. Данные SMART не показали каких-либо ухудшений, а системный журнал не выявил никаких сообщений об ошибках, связанных с жестким диском.

Затем я попытался снова запустить команду cmp, чтобы проверить, реальна ли ошибка записи, но несоответствие в этой позиции больше не возникало. Это была какая-то случайная ошибка во всем процессе чтения + оценки. Так что не полагайтесь на один запуск команды cmp; в случае обнаружения несоответствия запустите его снова. Если ошибка исчезнет, ​​то проигнорируйте первое несоответствие или попробуйте еще раз. Если ошибка не устранена, верните жесткий диск продавцу, так как он, скорее всего, неисправен и его деградация во времени может происходить быстрее по сравнению с исправным жестким диском.

.