красиво удалить данные на диске

Лучше if=/dev/urandom

и всё таки лучше if=/dev/zero - быстрее и потом можно будет проверить результат через cat /dev/sd[a-z] | hexdump

проверить результат

Зачем?!

чтобы со спокойной совестью снять шапочку из фольги и не гонять dd по нескольку раз, как любят советовать некоторые.

и всё таки лучше if=/dev/zero - быстрее

но хуже.

потом можно будет проверить

отведи /dev/urandom тройником в md5sum -, и проверяй потом ей же.

Только я не распарсил, зачем проверять?

чтобы со спокойной совестью снять шапочку из фольги и не гонять dd по нескольку раз, как любят советовать некоторые.

dd гоняют для того, что-бы остаточная намагниченность прошла.

Если тебя волнует такой пустяк как «остаточная намагниченность» то единственный способ побороть параною это несколько раз тщятельно промыть винчестер концентрированной соляной кислотой.

ты не совсем прав.

Конечно, «остаточная намагниченность» это миф и городская легенда — на сегодня плотность настолько высока, что для остатков нет никакого места, скорее наоборот, соседние данные сильно влияют на те, к которым доступ.

Однако. Устройство /dev/zero НЕ содержит информации. Его уникальность в том, что оно выдаёт последовательность битов(бесконечную), информационная ценность(энтропия) которых вполне конечна, и равна нулю. Теоретически, для сохранения такой последовательности необходимо и достаточно 0 битов.

Практически вопрос совсем не прост: будет ли устройство _действительно_ выделять биты под то, подо что выделять ничего не нужно? Да или нет? Ответ на этот вопрос очевидно зависит от наличия профита. Если профит есть, то его будут юзать. Если профита нет — не будут.

Очевидно, что профит есть хотя-бы по скорости — записать 0 бит всяко БЫСТРЕЕ. Но бывает-ли ситуации, когда устройство просят записать 0 информации? Ну кроме терминальных случаев стирания? Да. Бывают. Именно так поступает ПО тогда, когда ему нужно зарезервировать место, и когда ПО точно знает, СКОЛЬКО ему этого места надо. Если ПО так не сделает, место будет выделятся динамически, что естественно медленнее, и часто — намного. Например так выделяется место для файлов в p2p. ФС ессно в курсе, и даже команда cp НЕ копирует блоки из нулей. Она их тупо «создаёт», при этом место на диске естественно не выделяется. Но и сам диск может так делать, дабы быстрее работали программы в более древних OS, к примеру в windows (там нули AFAIK копируются, хоть и файл тоже можно создать без данных но любого размера). Кроме того, размер блока ФС не совпадает с размером сектора диска. Кроме того, перед записью на диск информация обрабатывается сложными алгоритмами, суть которых противоположна архиваторам — они не сжимают, а наоборот расширяют данные. Энтропия на бит уменьшается, дабы быть меньше 1. Нужно это для того, что-бы если какой-то бит потерялся, его можно было-бы вытащить из соседних. Однако, для правильной работы данного алгоритма необходимо, что-бы входная энтропия была-бы равно 1. Т.е. на входе должен быть либо /dev/random, либо статистически эквивалентный выхлоп сжимателя, который увеличивает энтропию до максимума.

Из всего вышесказанного следует, что если подать на вход диска биты с нулевой энтропией, то они перед записью будут сжаты практически в нулевой объём. Т.е. почти все сектара НЕ изменят своего состояния, а так и будут содержать старые данные, которые в теории несложно восстановить почти на все 100% (на практике восстановление невозможно без знаний деталей работы контроллера устройства. Для меня это проблема, для КГБ — это семечки).

Т.е. для грамотной очистки необходим источник, статистическая ценность информации которого равна 100%, т.е. /dev/urandom.

ЗЫЖ а есть ещё и скрытые области на диске, битые дорожки, кторые диск сам ремапит. Они тоже НЕ затираются и _могут_ содержать секретную информацию.

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

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

РК восстанавливает даже 666х проходную shred

А для простых смертных разница нулевая.

ну вообще есть специальная утилита. shred. Но ты можешь велосипедить дальше...