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

Question

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

Что отличает 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

Answer 1

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

история

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

К сожалению, примерно в это время разные производители исправили формат -c cpio (просто посмотрите страницу руководства для GNU cpio и опцию -H). В то время tar стал более портативным, чем cpio ... Прошло почти целое десятилетие, пока разные производители UNIX не разобрались в этом. Установленные GNU tar и 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 для указания команды постпроцессора - хотя я бы все же предпочел канал. Может быть, это полезно при записи на определенные устройства.

Answer 2

Как 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 или любой другой инструмент сжатия потоков, если хотите.)

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

Хотя ответы здесь уже очень хорошо сравнивают 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 .