Linux заполнить нулями свободное место

Как заполнить жесткий диск в Linux

Я тестирую фрагмент кода, и я хочу заполнить жесткий диск данными. Я обнаружил, что dd может делать огромные файлы в одно мгновение, но df не согласен. Вот что я пробовал:

dd if=/dev/zero of=filename bs=1 count=1 seek=$((10*1024*1024*1024))

ls -lh показывает файл 10G. Однако df -h показывает, что раздел не сжимался. Итак, что мне нужно сделать, чтобы сделать df распознать данные теперь? Я надеюсь на что-то быстрое, что я код в единичном тесте.

7 ответов

Проблема с трюком seek= заключается в том, что файловая система (обычно) умна: если часть файла никогда не была написана (и, следовательно, все нули), он не хочет выделять для этого какое-либо пространство — так, как вы видели, у вас может быть 10-гигабайтный файл, который не занимает места (это называется «разреженный файл», и может быть очень полезен в некоторых случаях, например, в некоторых реализациях базы данных).

Вы можете заставить пространство быть выделенным (например):

, который займет гораздо больше времени, но фактически заполнит диск. Я рекомендую сделать размер блока намного выше, чем один, потому что это определит, сколько системных вызовов обрабатывает процесс dd — чем меньше размер блока, тем больше системных вызовов, и, следовательно, медленнее будет работать. (Хотя за пределами 1 МБ или около того он, вероятно, не будет иметь большого значения и может даже замедлить работу . )

В качестве другого варианта для этого вы можете использовать да вместе с одной строкой и примерно в 10 раз быстрее, чем запуск dd if = /dev /urandom of = largefile. Как этот

Вы создали так называемый «разреженный файл» — файл, который, поскольку большая часть его пуста (т.е. читается как \ 0), не занимает места на диске, кроме того, что на самом деле написано (1B , после 10 ГБ пробела).

Я не верю, что вы могли бы создавать огромные файлы, занимая фактическое дисковое пространство в одно мгновение — физическое пространство означает, что файловой системе необходимо выделить блоки диска для вашего файла.

Я думаю, что вы застряли со старомодным «dd if = /dev /zero of = filename bs = 100M count = 100», который ограничен скоростью последовательной записи вашего диска.

Если вы просто проверяете случаи с заполненными файловыми системами, возможно, fallocate достаточно хорош. И быстрее! например.

Остановить использование seek и использовать очень большой bs и /или count . Поскольку вы делаете разреженный файл , и, очевидно, вам не нужно этого делать.

Если вы хотите буквально заполнить жесткий диск, сделайте следующее:

Вы можете дополнительно указать счетчик, если хотите ограничить размер, но если вы опустите счет, он будет работать только до тех пор, пока вы не выберете место на диске.

Как упоминалось выше, вы получите лучшую производительность, если вы установите размер блока 1 МБ (bs = 1M) вместо 1 B (bs = 1). Это займет некоторое время, но если вы хотите проверить ход выполнения своей команды, откройте отдельную консоль и запустите следующие команды:

Используйте PID dd в этой команде (замените PID на PID dd):

Затем перейдите на свой dd-терминал. Конечно, это ограниченное использование, когда вы просто пытаетесь заполнить диск (вы можете просто использовать df или du ​​для проверки свободного места на диске или размера файла соответственно). Однако есть и другие моменты, когда удобно делать вывод dd о его прогрессе.

Дополнительный кредит: одно практическое использование для обнуления свободного пространства заключается в том, что после этого вы можете удалить «нулевые» файлы и dd весь раздел (или диск, если вы обнулили все разделы), на образ диска файл (скажем, disk-backup.dd), а затем сжать файл. Свободное пространство теперь сильно сжимаемо, поэтому сжатое dd-изображение будет намного меньше исходного блочного устройства, содержимое которого оно содержит.

Shenanigans: запишите большой файл нулей и отправьте его по электронной почте всем своим друзьям. Скажите им, что это действительно здорово.

Вы создаете не разреженный файл 1 ТБ со следующей командой:

Это было полезно при тестировании того, что происходит, когда квоты превышены, или файловая система заполняется.

df -h показывает, что доступное пространство становится меньше.

Источник

заполнение нулями против случайного заполнения

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

PS: Я НЕ ТОЛЬКО беспокоюсь о своих данных, я время от времени продаю бывшие в употреблении компьютеры, и я бы предпочел, чтобы обычные покупатели джо не получали от них ничего смешного.

7 ответов 7

Многие учебные пособия предполагают, что я должен заполнить диск с /dev /urandom вместо /dev /zero, если я хочу, чтобы он был неустранимым.

Что бы вы ни делали, не используйте /dev/urandom .

На моем i7-3770 /dev/urandom производит удивительно 1 ГБ псевдослучайно генерируемых данных в минуту. Для жесткого диска емкостью 4 ТБ одно стирание с /dev/urandom займет более 66 часов!

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

печатает бесконечный поток байтов. Он использует AES в режиме CTR и пароль, считанный из /dev/random , поэтому он криптографически защищен для любого жесткого диска размером менее 1 000 000 ТБ.

Это также быстро. Очень быстро. На той же машине ему удавалось генерировать 1,5 ГБ в секунду, так что это в 90 раз быстрее, чем /dev/urandom . Это больше, чем может выдержать любой жесткий диск потребительского уровня.

[Я] это просто очень специализированные люди (читай правительственные учреждения), которые могут восстановить заполненный нулями диск, или что-то, что может сделать ваш обычный гик?

В разделе «Перезапись данных на жестком диске: Великая борьба за стирание» авторы приходят к выводу, что перезапись исходного диска (используется только для теста) один раз неслучайными данными снижает вероятность правильного восстановления одного бита до 92%. Это означает, что один байт (один символ ASCII) может быть восстановлен только с вероятностью 51%; и нет никакого способа сказать, был ли байт восстановлен правильно или нет.

В реальных сценариях (слабо используемый диск) вероятность падает до 56% для одного бита и всего 9% для одного байта.

Они взяли новый диск, трижды протерли его, чтобы имитировать кратковременное использование, написали короткий текст и один раз сотрили диск неслучайными данными. Это были результаты:

Безопасное удаление данных — Питер Гутманн — 1996
Аннотация
С использованием все более совершенных систем шифрования злоумышленник, желающий получить доступ к конфиденциальным данным, вынужден искать информацию в других местах. Одним из способов атаки является восстановление предположительно стертых данных с магнитных носителей или оперативной памяти.

Источник

как заполнить свободное на разделе место нулями?

Re: как заполнить свободное на разделе место нулями?

cat /dev/zero > file

Когда отвалится — значит всё свободное место забито нулями.

Re: как заполнить свободное на разделе место нулями?

file естественно должен быть на забиваемом разделе

Re: как заполнить свободное на разделе место нулями?

Или чуть быстрее

dd if=/dev/zero of=/path/file

Re: как заполнить свободное на разделе место нулями?

это с 512-байтным bs по умолчанию? Шутник.

Re: как заполнить свободное на разделе место нулями?

Оставайтесь на месте, отдел К выезжает

Re: как заполнить свободное на разделе место нулями?

Есть такое слово — называется кеширование.

Что мешает написать bs=4096?

Re: как заполнить свободное на разделе место нулями?

Re: как заполнить свободное на разделе место нулями?

sync еще неплохо бы.

Re: как заполнить свободное на разделе место нулями?

>Оставайтесь на месте, отдел К выезжает Тогда лучше использовать shred

Re: как заполнить свободное на разделе место нулями?

Только потом надо удалить файл.

Re: как заполнить свободное на разделе место нулями?

>как заполнить свободное на разделе место нулями?

А зачем, если не секрет.

Re: как заполнить свободное на разделе место нулями?

всем спасибо за ответы

>А зачем, если не секрет.

предпродажная подготовка=) продаю комп, а систему попросили не сносить

Источник

Затираем диск безвозвратно в Linux.

Опубликовано 14.07.2015 пользователем Johhny

При передаче/продаже кому-либо накопителя невольно задумываешься: не полезут ли восстанавливать там стертую информацию и как удалить файлы безвозвратно. В статье будем использовать команду dd, которая есть практически в каждом популярном Linux-дистрибутиве, для полного затирания данных на флешке.

Возьмем для примера флешку, на которой записан файл: some_interesting.txt Посмотрим все подключенные накопители, зарегистрированные в системе:

sdb — это наш 8Гб USB Flash drive.

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

dd if=/dev/sdb | hexdump -C

Бам! Вот и содержимое нашего текстового файла:

Для того чтобы правильно затереть диск потребуется его полная перезапись. Перезаписать можно случайными данными:

dd if=/dev/urandom of=/dev/sdb

dd if=/dev/zero of=/dev/sdb

После этого убедимся, что ничего уже не восстановить:

dd if=/dev/sdb | hexdump -C

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

Источник

Как стереть свободное место на диске в Linux?

Когда файл удален, его содержимое все равно может остаться в файловой системе, если явно не перезаписано чем-то другим. Команда wipe может безопасно удалять файлы, но не позволяет стереть свободное дисковое пространство, не используемое никакими файлами.

Что я должен использовать для достижения этой цели?

Предупреждение: Современное оборудование для дисков / SSD и современные файловые системы могут сжимать данные в местах, где вы не можете их удалить, поэтому этот процесс может все же оставить данные на диске. Единственными безопасными способами очистки данных являются команда ATA Secure Erase (если реализовано правильно) или физическое уничтожение. Также см. Как я могу надежно стереть всю информацию на жестком диске?

Вы можете использовать набор инструментов, который называется secure-delete.

Это имеет четыре инструмента:

srm — надежно удалить существующий файл
smem — надежно удалить следы файла из оперативной памяти
sfill — стереть все пространство, помеченное как пустое на вашем жестком диске
sswap — стереть все данные из пространства подкачки.

Из справочной страницы srm

srm предназначен для безопасного удаления данных на носителях, которые не могут быть восстановлены ворами, правоохранительными органами или другими угрозами. Алгоритм очистки основан на статье «Безопасное удаление данных из магнитной и твердотельной памяти», представленной на 6-м симпозиуме по безопасности Usenix Питером Гутманом, одним из ведущих гражданских криптографов.

Процесс безопасного удаления данных в srm выглядит следующим образом:

• 1 проход с 0xff
• 5 случайных проходов. /dev/urandom используется для безопасного RNG, если доступно.
• 27 проходов со специальными значениями, определенными Питером Гутманом.
• 5 случайных проходов. /dev/urandom используется для безопасного RNG, если доступно.
• Переименуйте файл в случайное значение
• Усекать файл

В качестве дополнительной меры безопасности файл открывается в режиме O_SYNC и после каждого прохода выполняется fsync() вызов. srm записывает 32k блоков с целью увеличения скорости, заполняя буферы дисковых кешей, чтобы заставить их сбрасывать и перезаписывать старые данные, которые принадлежали файлу.

Самый быстрый способ, если вам нужен только один проход и вы просто хотите заменить все на нули, это:

(запускается из каталога в файловой системе, которую вы хотите стереть)
_{(эта sync команда является мерой паранойи, которая обеспечивает запись всех данных на диск — интеллектуальный менеджер кэша может сработать, что он может отменить запись для любых ожидающих блоков, когда файл не связан )}

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

Этого должно быть достаточно, чтобы кто-то не мог прочитать содержимое старого файла без дорогостоящей криминалистической операции. Для более безопасного, но более медленного варианта замените /dev/zero на /dev/urandom . Для большей паранойи выполните несколько шагов с помощью /dev/urandom , хотя, если вам нужно столько усилий, shred утилита из пакета coreutils — это путь:

Обратите внимание, что в приведенном выше примере маленький файл измельчается перед созданием большего, поэтому его можно удалить, как только завершится создание большего, вместо того, чтобы ждать, пока он будет уничтожен, оставляя файловую систему с нулевым свободным пространством на время, которое требуется. Процесс уничтожения занимает много времени над большим файлом, и если вы не пытаетесь что-то скрыть от АНБ, на самом деле IMO не требуется.

Все вышеперечисленное должно работать на любой файловой системе.

Ограничения на размер файла:

Как отмечает DanMoulding в комментарии ниже, это может иметь проблемы с ограничением размера файла в некоторых файловых системах.

Для FAT32 это определенно будет проблемой из-за ограничения файла в 2 ГБ: большинство томов больше, чем это в наши дни (8 ТБ — это ограничение размера тома IIRC). Вы можете обойти эту проблему, cat /dev/zero пропуская большие выходные данные, split чтобы сгенерировать несколько небольших файлов и соответственно настроить этапы уничтожения и удаления.

С ext2 / 3/4 это не так важно: для стандартного / общего блока 4K ограничение размера файла составляет 2 ТБ, поэтому для этого потребуется большой объем (максимальный размер тома в этих условиях составляет 16 ТБ).

С (все еще экспериментальными) btrfs максимальные размеры файлов и томов составляют огромные 16EiB.

Под NTFS максимальная длина файла в некоторых случаях даже превышает максимальную длину тома.

Виртуальные устройства

Как недавно упоминалось в комментариях, существуют дополнительные соображения для виртуальных устройств:

Для редко выделяемых виртуальных дисков другие методы, такие как используемые, zerofree будут быстрее (хотя в отличие от этого, cat и dd это не стандартный инструмент, на который можно положиться в значительной степени в любой UNIX-подобной ОС).

Имейте в виду, что обнуление блока на разреженном виртуальном устройстве может не стереть блок на базовом физическом устройстве, на самом деле, я бы сказал, что это маловероятно — менеджер виртуальных дисков просто сделает блок больше не используемым. так что это может быть выделено для чего-то еще позже.

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

Для перечисленных выше проблем на виртуальных устройствах: если вы не управляете хостами и не можете безопасно стереть их нераспределенное пространство после очистки дисков в ВМ или перемещения виртуального устройства, вы ничего не можете с этим сделать после факт. Единственный выход — использовать полное шифрование диска с самого начала.так что ничто в незашифрованном виде не записано на физическом носителе. Конечно, в VM все еще может потребоваться очистка свободного пространства. Также обратите внимание, что FDE может сделать разреженные виртуальные устройства намного менее полезными, так как уровень виртуализации не может реально увидеть, какие блоки не используются. Если уровень файловой системы ОС отправляет команды обрезки на виртуальное устройство (как если бы это был SSD), и виртуальный контроллер интерпретирует их, то это может решить эту проблему, но я не знаю каких-либо обстоятельств, где это действительно происходит, и более широких обсуждение этого вопроса в другом месте (мы уже близки к тому, чтобы не обсуждать первоначальный вопрос, поэтому, если это вызвало у вас интерес, возможно, стоит поэкспериментировать и / или последующие вопросы).

Источник