3

Я получаю от 4 до 100 очень больших архивов tar (~ 20GB) каждый день. В прошлом я объединял их, просматривая каждый архив, который я вижу в файловой системе, и делая что-то подобное

/bin/tar -concatenate --file=allTars.tar receivedTar.tar

Однако проблема заключается в том, что, поскольку я объединяю все больше и больше tar-файлов, он должен прочитать до конца allTars.tar чтобы начать конкатенацию снова. Иногда для добавления другого файла tar требуется более 20 минут. Это слишком медленно, и мне не хватает согласованного времени доставки полного allTars.tar .

Я также попытался передать моей команде tar список файлов, например:

/bin/tar --concatenate --file=alltars.tar receiverTar1.tar receivedTar2.tar receivedTar3.tar...etc

Это дало очень странные результаты. allTars.tar будет ожидаемый размер (т.е. близко ко всем размерам файловсписок receivedTar.tar добавил вместе) , но , казалось, перезапись файлов при allTars.tar распаковывался.

Есть ли способ объединить все эти tar-файлы в одну команду или нет, поэтому не нужно каждый раз читать до конца архивируемого конкатенации и правильно распаковывать их со всеми файлами / данными?

|источник

4 ответа4

6

Этот вопрос довольно старый, но я бы хотел, чтобы мне было легче найти следующую информацию раньше. Так что, если кто-то еще сталкивается с этим, наслаждайтесь:

То, что Джефф описывает выше, является известной ошибкой в gnu tar (сообщается в августе 2008 года). Только первый архив (после параметра -f ) удаляет маркер EOF. Если вы попытаетесь объединить более двух архивов, последние архивы будут "спрятаны" за маркерами конца файла.

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

Источник: https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (и следующие сообщения)

Учитывая возраст ошибки, мне интересно, будет ли она когда-нибудь исправлена. Я сомневаюсь, что есть критическая масса, которая затронута.

Лучший способ обойти эту ошибку - использовать опцию -i , по крайней мере, для файлов .tar в вашей файловой системе.

Как указывает Джефф, tar --concatenate может занять много времени, чтобы достичь EOF, прежде чем он объединит следующий архив. Так что, если вы собираетесь застрять в "сломанном" архиве, для которого требуется опция tar -i чтобы распаковать, я предлагаю следующее:

Вместо использования tar --concatenate -f archive1.tar archive2.tar archive3.tar вам, вероятно, будет лучше запустить cat archive2.tar archive3.tar >> archive1.tar или pipe к dd если вы собираетесь записывать на ленту устройство. Также обратите внимание, что это может привести к неожиданному поведению, если ленты не обнулялись до (пере) записи новых данных на них. По этой причине в моей заявке я буду использовать вложенные тары, как это предлагается в комментариях под вопросом.

Приведенное выше предложение основано на следующем очень небольшом выборочном тесте:

time tar --concatenate -vf buffer.100025.tar buffer.100026.tar
  real  65m33.524s
  user  0m7.324s
  sys   2m50.399s

time cat buffer.100027.tar >> buffer.100028.tar
  real  46m34.101s
  user  0m0.853s
  sys   1m46.133s

Буфер.* Файлы .tar имеют размер 100 ГБ, система практически не работала, за исключением каждого из вызовов. Разница во времени достаточно значительна, так что я лично считаю этот тест действительным, несмотря на небольшой размер выборки, но вы можете сами сделать это и, вероятно, лучше всего выполнить такой тест на своем оборудовании.

|источник
4

Это не может помочь, но если вы готовы использовать опцию -i при извлечении из конечного архива, то вы можете просто cat гудроны вместе. Файл tar заканчивается заголовком, полным нулей и дополнительным заполнением нулями до конца записи. С --concatenate tar должен пройти через все заголовки, чтобы найти точное положение окончательного заголовка, чтобы начать перезапись там.

Если вы просто cat за тарами, у вас просто есть дополнительные нули между заголовками. Опция -i просит tar игнорировать эти нули между заголовками. Так что вы можете

cat  receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar

Кроме того, ваш пример tar --concatenate должен работать. Однако, если у вас есть один и тот же именованный файл в нескольких архивах tar, вы перепишете этот файл несколько раз, когда извлечете все из полученного tar.

|источник
0

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

tar -n --concatenate --file=target_file.tar  other_file.tar

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

|источник
-1

Поскольку конкатенация требует интенсивного ввода-вывода, я бы рекомендовал использовать либо 3 SSD (1 ТБ) в RAID 0. Один SSD на SATA 3 даст 500 Мб / с для чтения и аналогично для записи. Дорого, да, но быстрый х3.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .