Я только что узнал, что cpio имеет три режима: копирование, копирование и сквозное копирование.
Мне было интересно, каковы преимущества и недостатки cpio в режимах копирования и копирования по сравнению с tar. Когда лучше использовать cpio, а когда tar?
Аналогичный вопрос для cpio в режиме сквозной передачи по сравнению с cp.
Спасибо и привет!
Я не вижу причин использовать cpio по какой-либо другой причине, кроме копирования открытых файлов RPM через disrpm или rpm2cpio, но могут быть крайние случаи, когда cpio предпочтительнее дегтя.
Как tar, так и cpio — это конкурирующие форматы архивов, представленные в Версии 7. Unix в 1979 году, а затем включен в POSIX.1-1988, хотя остался только tar в следующем стандарте, POSIX.1-20011.
Формат файла Cpio менялся несколько раз и не оставался полностью совместимым между версиями. Например, теперь существует ASCII-кодированное представление информационных данных двоичного файла.
Tar более широко известен, с годами стал более универсальным и с большей вероятностью будет поддерживаться в данной системе. Однако Cpio по-прежнему используется в некоторых областях, например в формате Red Hat (RPM). RPM v5 (что, по общему признанию, неясно) использует xar вместо cpio.
Оба работают в большинстве Unix-подобных систем, хотя tar встречается чаще. Вот статистика установки Debian:
#rank name inst vote old recent no-files (maintainer)
13 tar 189206 172133 3707 13298 68 (Bdale Garbee)
61 cpio 189028 71664 96346 20920 98 (Anibal Monsalve Salazar)
Копирование. Используется для создания архива, аналогично tar -pc.
Копировать: используется для извлечения из архива, аналогично tar -px.
Проход: это в основном оба вышеперечисленных, похожие на tar -pc … |tar -px, но в одной команде (и, следовательно, микроскопически быстрее). Он похож на cp -pdr, хотя и cpio, и (особенно) tar имеют больше возможностей для настройки. Также обратите внимание на rsync -a, о котором люди часто забывают, так как он чаще используется при сетевом подключении.
Я не сравнивал их производительность, но ожидаю, что они будут очень похожи по процессору, памяти и размеру архива (после сжатия).
tar -pc file.tar file | tar -px file.tar? Какой цели это служит?
- person Motivated; 25.01.2019
tar -pzc my_dir |ssh otherserver tar -pzx копирования каталога между местоположениями без фактического tarball (скажем, у вас закончилось место в первой системе). Для обоих из них rsync -a предпочтительнее, хотя и немного сложнее в использовании.
- person Adam Katz; 25.01.2019
tar -pzc my_dir | ssh someserver tar -pzx? Разве первая команда не создает сжатый tar-архив, а затем распаковывает его?
- person Motivated; 25.01.2019
tar в себя по сети без создания временного файла для исходного копирования по сети, то я не могу объяснить это здесь, кроме как сказать, что это значительно превосходит scp -pr.
- person Adam Katz; 25.01.2019
tar самому себе. Например, когда вы говорите о временном файле, вы имеете в виду, что он сжат до такой степени, что позволяет передавать файл и распаковывается после его фиксации? Я хотел бы понять различные сценарии.
- person Motivated; 26.01.2019
tar может передавать данные. Вы имеете в виду, что команда `tar -pzc file.tar файл | ssh someserver tar -pzx file.tar не создает временный файл tar? Он архивирует, сжимает, транслирует, распаковывает, удаляет?
- person Motivated; 27.01.2019
TAR(1) так же хорош, как cpio(), если не лучше. Можно утверждать, что на самом деле он лучше, чем CPIO, потому что он вездесущ и проверен. Должна быть причина, по которой у нас везде смоляные шарики.
Почему cpio лучше tar? Ряд причин.
При написании сценариев гораздо лучше контролируется, какие файлы копируются, а какие нет, поскольку вы должны явно перечислить файлы, которые хотите скопировать. Например, что из следующего легче читать и понимать?
find . -type f -name '*.sh' -print | cpio -o | gzip >sh.cpio.gz
или на Солярисе:
find . -type f -name '*.sh' -print >/tmp/includeme
tar -cf - . -I /tmp/includeme | gzip >sh.tar.gz
или с гнутаром:
find . -type f -name '*.sh' -print >/tmp/includeme
tar -cf - . --files-from=/tmp/includeme | gzip >sh.tar.gz
Пара конкретных замечаний: для больших списков файлов вы не можете заключать find в обратные кавычки; длина командной строки будет превышена; вы должны использовать промежуточный файл. Отдельные команды find и tar по своей природе медленнее, поскольку действия выполняются последовательно.
Рассмотрим более сложный случай, когда вы хотите полностью запаковать дерево, но некоторые файлы в один tar, а остальные файлы в другой.
find . -depth -print >/tmp/files
egrep '\.sh$' /tmp/files | cpio -o | gzip >with.cpio.gz
egrep -v '\.sh$' /tmp/files | cpio -o | gzip >without.cpio.gz
или под Солярисом:
find . -depth -print >/tmp/files
egrep '\.sh$' /tmp/files >/tmp/with
tar -cf - . -I /tmp/with | gzip >with.tar.gz
tar -cf - . /tmp/without | gzip >without.tar.gz
## ^^-- no there's no missing argument here. It's just empty that way
или с гнутаром:
find . -depth -print >/tmp/files
egrep '\.sh$' /tmp/files >/tmp/with
tar -cf - . -I /tmp/with | gzip >with.tar.gz
tar -cf - . -X /tmp/without | gzip >without.tar.gz
Опять же, некоторые примечания: отдельные команды find и tar по своей природе медленнее. Создание большего количества промежуточных файлов создает больше беспорядка. gnutar кажется немного чище, но параметры командной строки по своей сути несовместимы!
Если вам нужно быстро скопировать большое количество файлов с одной машины на другую через загруженную сеть, вы можете запустить несколько cpio параллельно. Например:
find . -depth -print >/tmp/files
split /tmp/files
for F in /tmp/files?? ; do
cat $F | cpio -o | ssh destination "cd /target && cpio -idum" &
done
Обратите внимание, что было бы полезно, если бы вы могли разделить ввод на части одинакового размера. Для этого я создал утилиту под названием «npipe». npipe будет читать строки из стандартного ввода, создавать N выходных каналов и передавать им строки по мере использования каждой строки. Таким образом, если первая запись была большим файлом, на передачу которого ушло 10 минут, а остальные были маленькими файлами, на передачу которых ушло 2 минуты, вы не застряли бы в ожидании большого файла, а за ним стояла еще дюжина маленьких файлов. . Таким образом, вы в конечном итоге разделяете по запросу, а не строго по количеству строк или байтов в списке файлов. Аналогичная функциональность может быть достигнута с помощью возможности параллельного разветвления gnu-xargs, за исключением того, что аргументы помещаются в командную строку вместо их потоковой передачи на стандартный ввод.
find . -depth -print >/tmp/files
npipe -4 /tmp/files 'cpio -o | ssh destination "cd /target && cpio -idum"'
Как это быстрее? Почему бы не использовать NFS? Почему бы не использовать rsync? NFS по своей природе очень медленный, но, что более важно, использование любого отдельного инструмента по своей сути является однопоточным. rsync читает исходное дерево и записывает в целевое дерево по одному файлу за раз. Если у вас есть многопроцессорная машина (в то время я использовал 16 процессоров на машину), параллельная запись стала очень важной. Я ускорил копирование 8-гигабайтного дерева до 30 минут; это 4,6 МБ/сек! Конечно, это звучит медленно, поскольку 100-мегабитная сеть может легко работать со скоростью 5-10 МБ/с, но именно время создания inode делает ее медленной; в этом дереве было легко 500 000 файлов. Так что, если создание inode является узким местом, мне нужно было распараллелить эту операцию. Для сравнения, копирование файлов в однопоточном режиме заняло бы 4 часа. Это в 8 раз быстрее!
Вторая причина того, что это было быстрее, заключается в том, что параллельные каналы tcp менее уязвимы для потерянных пакетов здесь и там. Если один канал останавливается из-за потери пакета, другие, как правило, не затрагиваются. Я не совсем уверен, насколько это имело значение, но для многопоточных ядер это снова может быть более эффективным, поскольку рабочая нагрузка может быть распределена между всеми этими простаивающими процессорами.
По моему опыту, cpio в целом работает лучше, чем tar, а также является более переносимым аргументом (аргументы не меняются между версиями cpio!), хотя его можно не найти в некоторых системах (не установлен по умолчанию в RedHat) , но опять же, Solaris не поставляется с gzip по умолчанию.
