Я бы хотел воспользоваться опцией oflag=append для dd операция по добавлению содержимого в файл. Это сделано для увеличения размера базового файла для устройства цикла в случае, когда создание нового файла большего размера является слишком ресурсоемким.
Это возможно dd В любом случае это не лучший вариант, но он лучший, о котором я знаю. Лучшие предложения приветствуются!
На моем сервере CentOS 4.8 X86_64 работает coreutils 5.2.1. Версия dd поставляемый с этой версией coreutils, не поддерживает oflag вариант. В официальном репо нет более новой версии.
Я замечаю последняя версия coreutils равен 8,5, и предположим, что где-то между 5.2.1 и 8.5 значение oflag опция была добавлена.
Предполагая, что мне нужно обновить coreutils до версии более новой, чем та, которая в настоящее время поставляется с CentOS 4.8 x86_64:
dd поддержать oflag вариант?Я не знаю никаких альтернативных методов, чтобы делать то, что вы хотите, навскидку.
Обновление кажется опасным; шансы в значительной степени в пользу обратной несовместимости изменения где-то в длинном списке двоичных файлов в coreutils. Практически каждый скрипт в вашей системе использует двоичные файлы из coreutils, поэтому обратное несовместимое изменение в неправильном месте может нанести ущерб вашему компьютеру.
Следующий вариант: получить для этого бинарный RPM. Я считаю это маловероятным, если вы не построите его самостоятельно.
Тем не менее, что вы могли бы безопасно сделать, так это собрать исходный код coreutils (никогда этого не делал, но, вероятно, это просто configure, make, make install) до части make включительно. Не выполняйте "make install". Затем выберите новый dd из вновь созданных двоичных файлов, поместите его в / bin как dd_new, и все готово. Целый и невредимый.
То есть при условии, что новые coreutils построены на вашем старом glibc :)
Я думаю, что вы можете выполнить желаемую задачу dd с помощью "seek" без необходимости создавать новый coreutils.
ls -l loopfile
Получите размер, разделите на 1024, затем:
dd if=/dev/zero of=loopfile bs=1M seek=1024 count=2048
(это записывается блоками 1M, поэтому пропускает 1G вывода, а затем добавляет 2G в файл. Убедитесь, что размер блока равномерно делится на размер файла. Вероятно, вам понадобится размер блока 1k и гораздо большее число поиска и подсчета )
Я бы провел небольшие эксперименты. Вам также может понадобиться "conv=notrunc".