Интересное использование tar …, но что происходит?

Это пишет архив в стандартный вывод, затем передает его по каналу к подпроцессу - перенесенный круглыми скобками - который изменяется на другой каталог и читает/извлекает из стандартного входа. Это что символ тире после f средства аргумента. Это в основном копирует все видимые файлы и подкаталоги текущего каталога к другому каталогу.

Это - уникальное использование каналов. В основном первый tar обычно пишет непосредственно в файл, но вместо этого он собирается записать в stdout (-), который затем перенаправляется к другому tar, который берет stdin, а не файл. В основном это - то же самое как смолящий в файл и не смолящий позже, кроме без промежуточного файла.

Для каталога с 25 000 пустых файлов:

$ time { tar -cf - * | (cd ../bar; tar -xf - ); }
real    0m4.209s
user    0m0.724s
sys 0m3.380s

$ time { cp * ../baz/; }
real    0m18.727s
user    0m0.644s
sys 0m7.127s

Для каталога с 4 файлами 1 073 741 824 байтов (1 ГБ) каждый

$ time { tar -cf - * | (cd ../bar; tar -xf - ); }
real    3m44.007s
user    0m3.390s
sys 0m25.644s

$ time { cp * ../baz/; }
real    3m11.197s
user    0m0.023s
sys 0m9.576s

Мое предположение является этим явлением, очень зависимо от файловой системы. Если я прав, что Вы будете видеть решительное различие между файловой системой, которая специализируется на многочисленных маленьких файлах, таких как reiserfs 3.6 и файловая система, которая лучше в обработке больших файлов.

(Я запустил вышеупомянутые тесты на HFS +.)

tar cf - * | (cd <dest> ; tar xf - )

движение должно смолить все не скрытые файлы/каталоги текущего каталога к stdout, затем передавая это по каналу в stdin новых подоболочек. Та оболочка сначала изменяет текущий рабочий каталог на <dest>, и затем не смолит его к тому каталогу.

tar cf - *

Это использует tar для отправки * к stdout

|

Это делает очевидное перенаправление stdout к...

(cd <dest> ; tar xf - )

Это, которое изменяет PWD на соответствующее местоположение и затем извлекает из stdin

Я не знаю, почему это было бы быстрее, чем rsync, поскольку нет никакого включенного сжатия.

Некоторые старые версии CP не имели-f/-p (и подобный) опции для сохранения полномочий, таким образом, этот прием tar сделал задание.

Решение для tar сохранит символьные ссылки, тогда как CP просто сделает копии и уничтожит ссылки.

tar был стандартной утилитой Unix намного дольше, чем rsync. Вы, более вероятно, найдете его в ситуации, когда иерархия каталогов должна будет быть скопирована в другое местоположение (даже другой компьютер). rsync, вероятно, легче использовать эти дни, но медленнее, потому что он сравнивает и источник и места назначения и синхронизация их. tar просто копирует в одном направлении.

Если у Вас есть GNU cp (который все основанные на Linux системы будут), cp --archive будет работать, даже на трудно связанных файлах, и tar не нужен.

Как это происходит, коллега записал почти идентичную команду в один из наших сценариев. После того, как я провел некоторое время, ломающее голову над ним, я спросил, почему он использовал это, а не cp. Его ответ, поскольку я вспоминаю это, был этим cp является медленным при создании копии от одной файловой системы до другого.

Верно ли это, потребовал бы большего количества тестирования, чем я хочу потратить на вопрос, но это делает определенное количество смысла. Первое tar обработайте чтения от исходного устройства, как можно быстрее только ожидающего того устройства для чтения. Между тем, второе tar обработайте чтения от его входного канала и записей как можно быстрее. Этому, возможно, придется ожидать входа, но если записи на устройстве назначения будут медленнее, чем чтения на исходном устройстве, то это будет только ожидать на устройстве назначения. Сингл cp команда должна будет ожидать и на источнике и на устройствах назначения.

С другой стороны, современные операционные системы делают довольно хорошее задание предварительного кэширования операций IO. Это совершенно возможно cp проведет большую часть его времени, ожидая на записях и получая чтения из памяти, а не само устройство. Кажется, что можно было бы быть нужны действительно твердые данные к, выбрал использование два tar команды, а не более простое cp команда.

Я считаю, что tar выполнит операцию «слияния» в стиле Windows с глубоко вложенными каталогами, тогда как cp перезапишет подкаталоги.

Например, если у вас есть макет:

dir/subdir/file1

и вы копируете его в место назначения, которое содержит:

dir/subdir/file2

Затем с копией у вас останется:

dir/subdir/file1

Но с командой tar ваш пункт назначения будет содержать:

dir/subdir/file1
dir/subdir/file2