Сжатие потока «на лету», которое не распространяется на аппаратные ресурсы?

У меня есть 200 ГБ свободного дискового пространства, 16 ГБ ОЗУ (из которых ~ 1 ГБ занято рабочим столом и ядром) и 6 ГБ подкачки.

У меня есть внешний SSD на 240 ГБ, из которых ¹ используется 70 ГБ, а остальное свободно, и мне нужно сделать резервную копию на моем диске.

Обычно я dd if=/dev/sdb of=Desktop/disk.imgсначала выполняю диск, а затем сжимаю его, но создание образа сначала не вариант, так как для этого потребуется гораздо больше места на диске, чем у меня, даже несмотря на то, что этап сжатия приведет к сжатию свободного пространства, поэтому Конечный архив легко помещается на моем диске.

ddзаписывает в STDOUT по умолчанию и gzipможет читать из STDIN, поэтому теоретически я могу писать dd if=/dev/sdb | gzip -9 -, но gzipчтение байтов занимает значительно больше времени, чем ddможет их произвести.

От man pipe:

Данные, записанные в конец записи канала, буферизуются ядром до тех пор, пока они не будут прочитаны из конца чтения канала.

Я представляю себя |как настоящий канал - одно приложение помещает данные, а другое - как можно быстрее выводит данные из очереди канала.

Что, когда программа на левой стороне записывает больше данных быстрее, чем другая сторона канала, может рассчитывать на их обработку? Будет ли это вызывать чрезмерное использование памяти или подкачки, или ядро ​​попытается создать FIFO на диске, заполнив тем самым диск? Или он просто потерпит неудачу, SIGPIPE Broken pipeесли буфер слишком велик?

По сути, это сводится к двум вопросам:

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

_{Примечание 1: я не могу просто скопировать точно первые 70 использованных ГБ и ожидать получить работающую систему или файловую систему из-за фрагментации и других вещей, которые потребуют целостности всего содержимого.}

Технически вам даже не нужно dd:

gzip < /dev/drive > drive.img.gz

Если вы используете dd, вы всегда должны идти с большим, чем по умолчанию, размером блока, таким как адский вызов системного вызова dd bs=1Mили страдать от него (по ddумолчанию размер блока составляет 512 байт, так как это read()s и write()s, то есть 4096syscalls per MiB, слишком много накладных расходов).

gzip -9использует гораздо больше процессора с очень мало, чтобы показать это. Если gzipэто замедляет работу, снизьте уровень сжатия или используйте другой (более быстрый) метод сжатия.

Если вы делаете резервные копии на основе файлов, а не ddизображений, у вас может быть логика, которая решает, сжимать ли вообще или нет (делать это бессмысленно для разных типов файлов). dar( tarальтернатива`) - один из примеров, у которого есть варианты сделать это.

Если у вас свободное пространство ZERO (потому что это твердотельный накопитель, который надежно возвращает ноль после TRIM, и вы запустили fstrimи сбросили кэши), вы также можете использовать ddс conv=sparseфлагом, чтобы создать несжатый, монтируемый на петлю, разреженный образ, который использует нулевое дисковое пространство для нулевых областей. , Требует, чтобы файл образа был поддержан файловой системой, которая поддерживает разреженные файлы.

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

ddчитает и записывает данные по одному блоку за раз, и у него только один ожидающий блок. Так

valgrind dd if=/dev/zero status=progress of=/dev/null bs=1M

показывает, что ddиспользует примерно 1 МБ памяти. Вы можете поиграть с размером блока и сбросить valgrind, чтобы увидеть влияние на ddскорость.

Когда вы переходите на канал gzip, ddпросто замедляетесь, чтобы соответствовать gzipскорости. Его использование памяти не увеличивается и не заставляет ядро ​​хранить буферы на диске (ядро не знает, как это сделать, кроме как через swap). Разорванная труба случается только тогда, когда один из концов трубы умирает; смотрите signal(7)и write(2)для деталей.

таким образом

dd if=... iconv=fullblock bs=1M | gzip -9 > ...

это безопасный способ сделать то, что вы после.

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

strace dd if=/dev/zero bs=1M | (sleep 60; cat > /dev/null)

Вы увидите, что ddчитает 1MB, а затем выдает, write()который сидит в ожидании одной минуты, пока sleepработает. Вот как уравновешиваются обе стороны канала: ядро ​​блокирует запись, если процесс записи идет слишком быстро, и блокирует чтение, если процесс чтения слишком быстрый.

Нет никаких отрицательных последствий, кроме производительности: канал имеет буфер, который обычно составляет 64 КБ, и после этого запись в канал просто блокируется, пока не будет gzipпрочитано еще несколько данных.

Отвечая на реальный вопрос о том, как это работает: «что если программа на левой стороне записывает больше данных быстрее, чем другая сторона канала может рассчитывать на их обработку?»

Этого не происходит В канале имеется довольно маленький буфер ограниченного размера; Посмотрите, насколько большой буфер трубы?

Когда буфер канала заполнен, программа-отправитель блокируется . Когда он выполняет вызов записи, ядро ​​не вернет управление программе, пока данные не будут записаны в буфер. Это дает процессору ЦП время, в течение которого необходимо очистить буфер.

Может быть, вам нужны только файлы, затем используйте tar. Вы можете заполнить нулями блоки, которые не содержат ничего, что вы хотите, кто-то уже спрашивал об этом. Очистить неиспользуемое пространство с нулями (ext3, ext4)

Тогда есть, pigzчто обычно быстрее, чем gzip.