Почему GNU shred быстрее, чем dd, при заполнении диска случайными данными?

Почему GNU shred быстрее, чем dd, при заполнении диска случайными данными?

При безопасном стирании данных с жесткого диска перед его выводом из эксплуатации я заметил, что на это dd if=/dev/urandom of=/dev/sdaуходит почти целый день, тогда как shred -vf -n 1 /dev/sdaна том же компьютере и том же диске на это уходит всего пара часов.

Как это возможно? Я предполагаю, что узкое место — ограниченный выход /dev/urandom. Использует ли shred какой-то генератор псевдослучайности, который менее случаен и достаточен только для своей единственной цели (т. е. более эффективен), чем urandom?

решение1

Измельчитьиспользует внутренний псевдослучайный генератор

По умолчанию эти команды используют внутренний псевдослучайный генератор, инициализируемый небольшим количеством энтропии, но могут быть направлены на использование внешнего источника с помощью опции --random-source=file. Ошибка выдается, если файл не содержит достаточно байтов.

Например, файл устройства/dev/urandomможет использоваться как источник случайных данных. Обычно это устройство собирает окружающий шум от драйверов устройств и других источников в энтропийный пул и использует пул для генерации случайных битов. Если в пуле недостаточно данных, устройство повторно использует внутренний пул для создания большего количества битов, используя криптографически безопасный генератор псевдослучайных чисел. Но имейте в виду, что это устройство не предназначено для массовой генерации случайных данных и относительно медленный.

Я не убежден, что случайные данные более эффективны, чемодин проходизнули(или любое другое значение байта) при сокрытии предыдущего содержимого.

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

решение2

Я думаю, это скорее вызвано ddиспользованием меньших фрагментов для записи данных. Попробуйте dd if=... of=... bs=(1<<20)посмотреть, будет ли это работать лучше.

Связанный контент