В чем разница между форматами архивных файлов TAR и CPIO?

Мне любопытно, я немного почитал, но у меня остались вопросы.

Что отличает CPIO от TAR? В другом вопросе мне сказали, что tar предназначен для объединения многих файлов в 1 архив, который обычно является gzip'd или bzip'd.

Также мне сказали, что TAR не может сжимать из STDOUT. Я хочу заархивировать / сжать снимки ZFS для резервного копирования. Мне было интересно, смогу ли я объединить CPIO с bzip2, чтобы получить этот эффект.

Или у меня совершенно неверная идея? Разве это не цель CPIO?

К таким командам я пришел после прочтения, поэтому документы Oracle о резервном копировании снимков ZFS.

# Backup snapshot to cpio and bzip2 archive
zfs send media/mypictures@20070607 | cpio -o | bzip2 -9c > ~/backups/20070607.bz2

# Restore snapshot from cpio and bzip2 archive
zfs recieve media/mypictures@20070607 | cpio -i | bunzip2 -c ~/backups/20070607.bz2

Оба tarи cpioимеют единственную цель: объединить множество отдельных файлов в один поток. Они не сжимают данные. (Эти дни tarболее популярны из-за своей относительной простоты - они могут принимать входные файлы в качестве аргументов, вместо того, чтобы соединяться с ними findкак cpioесть.)

В вашем случае вам не нужен ни один из этих инструментов; они не будут иметь никакого полезного эффекта, потому что у вас не так много отдельных файлов. zfs sendуже сделал то же самое, tarчто сделал бы. Таким образом , у вас нет никаких файлов, только поток безымянного.

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

zfs send media/mypictures@20070607 | gzip -c > ~/backups/20070607.gz

gzip -dc ~/backups/20070607.gz | zfs receive media/mypictures@20070607

(Вы можете заменить gzipс xzили bzip2или любым другим инструментом потока сжатия, если вы хотите.)

В дополнение к тому, что было сказано ранее Гравитацией и Полом :

история

В «старые времена», CPIO (с опцией -cиспользуется) был инструмент , чтобы использовать , когда он пришел , чтобы переместить файлы в другие дериваты UNIX , так как это было более портативным и гибким , чем смолы . Но проблемы переносимости смолы можно считать решенными с конца 1980-х годов.

К сожалению, примерно в это время разные производители исправили -cформат cpio (просто посмотрите страницу руководства по GNU cpio и ее опцию -H). В то время tar стал более переносимым, чем cpio ... Прошло почти целое десятилетие, пока разные производители UNIX не разобрались в этом. Имея GNU дегтя и GNU CPIO установлен был обязательным для всех администраторов , которые должны были иметь дело с лентами из различных источников , тогда (даже в настоящее время я полагаю).

Пользовательский интерфейс

tar может использовать файл конфигурации ленты, где администратор может настроить накопители на магнитной ленте, подключенные к системе. Затем пользователь просто сказал бы: «Ну, я возьму ленточный накопитель 1», вместо того, чтобы запоминать точный узел устройства для ленты (что может быть очень запутанным, а также не стандартизированным на разных платформах UNIX.

Но главное отличие заключается в следующем:

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

cpio архивирует только те файлы или каталоги, к которым оно относится, но не выполняет рекурсивный поиск в подкаталогах. Также cpio получает список элементов, которые будут заархивированы из stdin - поэтому он почти всегда используется в сочетании с find .

Команда cpio часто выглядит пугающе для новичка по сравнению с tar :

 $ find myfiles -depth -print0 | cpio -ovc0 | gzip -7 > myfiles.cpio.gz
 $ tar czvf myfiles.tar.gz myfiles

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

Также GNU tar предлагает опцию, -zкоторая заставляет архив сжиматься с помощью GNU zip на лету, что делает вещи еще проще.

С другой стороны, можно делать отличные вещи с помощью команды find & cpio . На самом деле это более UNIX-подобный подход: зачем включать поиск по дереву каталогов в cpio, если уже есть инструмент, который позаботится почти обо всем, что только можно придумать: find . На ум приходят только резервные копии файлов, которые новее определенной даты, ограничение файлов теми, которые находятся в той же файловой системе, или фильтрация поиска-вывода с grep -vцелью исключения определенных файлов ...

Люди из GNU tar потратили много времени на то, чтобы включить те вещи, которые раньше были возможны только с помощью cpio . Фактически оба инструмента учились друг у друга - но только cpio может читать формат tar - не наоборот.

обработка смолы и вывода

Последнее примечание к тому, что вы сказали:

Также мне сказали, что TAR не может сжимать из STDOUT. Я хочу заархивировать / сжать снимки ZFS для резервного копирования. Мне было интересно, смогу ли я объединить CPIO с bzip2, чтобы получить этот эффект.

Ну, любая версия tar (GNU или нет) может использоваться в конвейере. Просто используйте знак минус ( -) в качестве имени архива:

 $ tar cvf - myfiles | bzip > myfiles.tar.bz

Также GNU tar предлагает опцию --to-commandдля указания команды постпроцессора - хотя я бы все же предпочел трубу. Может быть, это полезно при записи на определенные устройства.

У tar и cpio, по сути, одна и та же функция, которая заключается в создании единого непрерывного файла из входных данных нескольких файлов и каталогов. Первоначально это было для того, чтобы поместить результат на ленту, но в наши дни его обычно используют для подачи в утилиту сжатия, как вы делали выше. Это связано с тем, что сжатие одного большого файла требует больше времени и пространства, чем сжатие большого количества маленьких файлов. Вы должны заметить, что многие форматы изображений (png, jpg и т. Д.) Уже сильно сжаты и могут на самом деле стать немного больше, если использовать утилиту сжатия.

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

tar действительно может принимать входные данные в stdin и выводить в stdout - который затем будет передан в bzip2, как у вас, или что-то подобное. Если вызывается с параметром «z», он автоматически вызовет gzip на выходе.

Я попросил техническую поддержку HP в ок. 1996, почему использование cpioзакончено tar.

Мне сказали, что ленты растягиваются и изнашиваются. Когда tarдостигает нечитаемой части ленты, происходит сбой и возвращается номер ошибки. Когда cpioдостигает нечитаемой части, она переходит к следующему читаемому блоку, выполняет повторную синхронизацию и продолжается.

Я никогда не видел документацию, подтверждающую это, но всегда использовал cpio.

Также стоит отметить: на (по крайней мере) FreeBSD и Mac OS X вы можете манипулировать файлами cpio с помощью tar. BSD tar использует libarchive под капотом, поэтому он может обрабатывать cpio, pax, shar ...

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

Хотя ответы здесь уже сравниваются cpioи tarочень хорошо, я хотел бы выделить одну из cpioфункций, называемых конвейерным режимом, которая позволяет более эффективно копировать отдельные файлы (например, через findи фильтровать), сохраняя при этом их структуру каталогов. Эта функция хорошо документирована и в своей основной предпосылке выглядит следующим образом:

find . <predicates> | cpio -pdmv /destination/dir

Эквивалент с tarбудет включать что-то вроде этого:

find . <predicates> | tar -T - -cf - | (cd /destination/dir; tar xvf -)

Конечно, есть и другие альтернативы, такие как rsyncи cp --parentsобсуждаемые в другой ветке , но ничто не сравнится с гибкостью, предлагаемой комбинацией findи cpio. Ввиду tarповсеместного создания архивов, это единственная причина, по которой я до сих пор пользуюсь cpio.