Каковы различия между tar GNU и bsdtar?

Я не имею HP-UX в наличии для меня, и я никогда не был крупным поклонником HP-UX.

Кажется, что на Linux, для каждого процесса или возможно пределе в расчете на пользователя на то, сколько дочерних процессов существует. Вы видите его с limit Встроенный Zsh (кажется, походит ulimit -u в ударе):

1002 % limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         16136
  ...

Это находится на ноутбуке Linux Arch.

Я записал немного программы для тестирования того предела:

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>

volatile int sigchld_cnt = 0;

voida
sigchld_hdlr(int signo)
{
        ++sigchld_cnt;
}

int
main(int ac, char **av)
{
        int looping = 1;
        int child_cnt = 0;
        int status;

        signal(SIGCHLD, sigchld_hdlr);

        printf("Parent PID %d\n", getpid());

        while (looping)
        {
                switch (fork())
                {
                case 0:
                        _exit(0);
                        break;
                case -1:
                        fprintf(stderr, "Problem with fork(), %d children: %s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                        break;
                default:
                        ++child_cnt;
                        break;
                }
        }

        fprintf(stderr, "Sleeping, forked %d child processes\n", child_cnt);
        fprintf(stderr, "Received %d sigchild\n", sigchld_cnt);
        sleep(10);

        looping = 1;
        do {
                int x = wait(&status);

                if (x != -1)
                        --child_cnt;
                else if (errno != EINTR) {
                        fprintf(stderr, "wait() problem %d children left: \%s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                }
        } while (looping);

        printf("%d children left, %d SIGCHLD\n", child_cnt, sigchld_cnt);

        return 0;
}

Было удивительно трудно "забрать" все зомби путем вызова wait(2) достаточно раз. Кроме того, количество полученных сигналов SIGCHLD никогда не является тем же как количеством разветвленных дочерних процессов: Я полагаю, что ядро Linux иногда отправляет 1 SIGCHLD за многими дочерними процессами, из которых выходят.

Так или иначе, на моем ноутбуке Linux Arch, я получаю 16 088 дочерних процессов, разветвленных, и это должно быть числом зомби, поскольку программа не делает wait(2) системные вызовы в обработчике сигналов.

На моем сервере Slackware 12 я получаю 6 076 дочерних процессов, который тесно соответствует значению maxproc 6079. Мой идентификатор пользователя имеет 2 других выполнения процессов, sshd и Zsh. Наряду с первым, экземпляр незомби программы выше этого делает 6079.

fork(2) системный вызов приводит к сбою с "Ресурсом временно недоступную" ошибку. Я не вижу никакого другого доказательства того, какой ресурс недоступен. Я действительно получаю несколько различные числа, если я запускаю свою программу одновременно в 2 различных xterms, но они составляют в целом то же число, как будто я выполняю его в одном xterm. Я предполагаю, что это - записи таблицы процессов, или подкачка или некоторый ресурс в масштабе всей системы и не только произвольный предел.

У меня нет ничего больше работающего для примерения его прямо сейчас.

48
13.04.2017, 15:36
5 ответов

Ubuntu bsdtar на самом деле реализация tar, связанная libarchive; и это должно дифференцироваться от классического bsdtar. Некоторые варианты BSD действительно используют libarchive для их реализации tar, например, FreeBSD.

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

Поскольку visualication вставил аннотацию из Ubuntu, существует несколько вещей там, которые характерны для libarchive:

  1. libarchive по определению библиотека, и отличающийся от обоих классических bsdtar и GNUtar таким образом.
  2. libarchive не может считать некоторые более старые неясные изменения tar GNU, самый известный кодировал некоторых заголовков в base64, так, чтобы файлом tar был 7-разрядный чистый ASCII (это имело место для 1.13.6-1.13.11 и изменилось в 1.13.12, тот код был только официально в tar в течение 2 недель),
  3. libarchive bsdtar считает файлы не-tar (например, zip, iso9660, cpio), но классический bsdtar не будет.

Теперь, когда мы добрались libarchive из пути это главным образом сводится к тому, что поддерживается в классическом bsdtar.

Вы видите страницы справочника сами здесь:

В Вашем исходном вопросе Вы спросили, что является преимуществами для классического bsdtar, и я не уверен, что существует действительно любой. Единственное время это действительно имеет значение, - то, если Вы пробуете к записи сценариев оболочки, которые должны работать над всеми системами; необходимо удостовериться, чему Вы передаете tar на самом деле допустимо во всех вариантах.

GNUtar, libarchive bsdtar, классический bsdtar, star и BusyBox tar конечно, реализации tar, с которыми Вы столкнетесь большую часть времени, но я уверен, что существуют другие там (ранний QNX, например). libarchive/GNUtar/star наиболее упакованы функцией, но во многих отношениях они долго отклонялись от исходных стандартов (возможно к лучшему).

30
27.01.2020, 19:34

Из описания пакета Ubuntu (http://packages.ubuntu.com/de/lucid/bsdtar)

"bsdtar программа имеет много преимуществ перед предыдущими реализациями tar:

  • Библиотека. Так как базовая функциональность находится в библиотеке, она может использоваться другими инструментами, такими как pkg_add.
  • Автоматическое обнаружение формата. Libarchive автоматически обнаруживает сжатие (none/gzip/bzip2) и формат (старый tar, ustar, gnutar, мир, cpio, iso9660, zip) при чтении архивов. Это делает это для любого источника данных.
  • Поддержка Формата обмена мира. Это - расширение POSIX/SUSv3 старого "ustar" формата tar, который добавляет произвольные расширенные атрибуты к каждой записи. Делает все, что формат tar GNU делает, только лучше.
  • Флаги файла дескрипторов, ACLs, произвольные пути, и т.д. Формат обмена мира поддерживает атрибуты ключа/значения с помощью легко расширяемой техники. Произвольные пути, названия группы, имена пользователей, размеры файла являются частью стандарта POSIX; libarchive расширяет это с помощью поддержки флагов файла, ACLs и произвольных номеров устройств.
  • Поддержка tar GNU. Libarchive читает большинство архивов tar GNU. Если существует спрос, это может быть улучшено далее."
13
27.01.2020, 19:34

Следующее основано на чтении, не испытывают - я только начинаю с Freebsd, таким образом, у меня нет почти реального опыта с ним (я происхожу из главным образом Linux). Я приношу извинения (и кротко требуйте исправления), если я пропустил что-то важное и что я говорю, вот мусор...

От моего чтения страниц руководства (последний раз один ref'd выше http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=1) tar Freebsd недостает (-d, - разность, - выдерживают сравнение), возможность. Это не удивительно, поскольку авторы дампа/восстановления Freebsd, кажется, не обеспечили ничего как это также.

Я не знаю наверняка, включит ли tar Гну все метаданные UFS, поскольку tar Freebsd, как говорят, делает, и это - важная проблема. Но для моего вкуса, я никогда не могу полагать, что дамп завершается, пока я не сохранил сумму MD5 выходного файла И ЗАТЕМ сравнил файл дампа с данными, которые я только что, предположительно, вывел. Различные проблемы могут привести к выведенным данным, являющимся отличающимся от того, что находится на диске. (Не только изменения файла, но и ошибки диска, ошибки памяти, отказы машины, и так далее. Все из которых на самом деле произошли со мной.)

По моему собственному мнению это заставляет Гну смолить единственную опцию, я до сих пор нашел для создания истинных резервных копий на запасе систему Freebsd.

Я нежно любил бы учиться иначе, FWIW. Я предпочел бы использовать собственные утилиты, по крайней мере, для резервных копий клонирования и твердого восстановления раздела. Но если нельзя проверить правильность дампа, я не вижу точку в том, чтобы потрудиться создать то.

1
27.01.2020, 19:34

BSDTAR VS TAL плюс гораздо больше

вот одна выгода !!

Я собираюсь пойти на 5 тему здесь (и уйти по теме, но он охватил то, что вы тоже хотите):

  1. BSDTAR VS TAR
  2. Редкие файлы против
  3. Толстые и тонкие Файлы / LUN с BTRFS
  4. Толстые и тонкие файлы / LUN без BTRFS
  5. Развлекаются между толстыми и тонкими и тем, как он не применяется к просто Luns

BSDTAR обрабатывает редкие файлы лучше, чем регулярно TAR

  • BSDTAR возьмет все нули и просто метаданные им вверх
  • TAR, фактически обрабатывает каждый ноль

* Пример: Представьте себе 20 туберкулезный файл (называемый biglun) с 10 мегабандаминальными данными в течение всего 20 туберкулеза (Biglun) ... Теперь, поскольку это редкий файл, он займет только 10 мэг на диске.

Как сделать редкий файл:

редкий файл - как это сделать - обнаружить его - все Редкие файлы похожи на «тонкие» LUN (если бы вы использовали его для LUN). «Толстые» Лун были бы разной историей.

* Вернуться к теме:

  • Tall up Biglun сделает смолу пройти через все 10 мегапотавшими вместе со всеми ~ 20 ТБ хуже Zeroes, распространяющихся через LUN ... это займет некоторое время, и TAR-файл будет довольно большим. Также - извлечение его - я никогда не делал экстракт файла TAR по редким файлам, но это может быть не красиво; Я мог бы ошибаться здесь.

  • BSDTARRING BIGLUN будет просто обрабатывать 10 мегабайтов данных и сделать небольшие метаданные для ~ 20TB Zeros.

Преимущество? Ну много них; Я только что написал несколько выше.

Это похоже на rsync vs cp

  • также, если вы rsync гигантский редкий файл, он будет вести себя как TAR
  • , если вы CP гигантский файл, он будет вести себя автоматически, как BSDTAR (вы можете изменить CP's Поведение, чтобы перейти на нули, или не перейти на нули)

Лично, я люблю представить редкие файлы, такие как тонкие LUN, а регулярные файлы, такие как густые Luns ...

Следующая тема BTRFS Тонкие против толстых густых густых люнтов:

  • с файловыми системами, такими как BTRFS , тонкие LUN ​​- редкие файлы (сделайте его с усечением, как в документе Wiki).

      Trunchate -S <Размер в килобайтах> Имя файла
     

    Совет: Резервное копирование с BSDTAR , копирование с CP

  • Толстые LUN ​​- это обычные файлы с атрибутом + C (+ C, чтобы он не сделал корова, копировать на Напишите, чтобы все пишеты по сути придерживаются туда, где он выделяется, и никакие новые пишеты не происходят за этот файл, когда есть перезаписи или удаления - исследование COW и BTRFS ). Вместо того, чтобы сделать файл с усечением, сделайте его с помощью «FALLOCATEL -L»

     FALLACOUNT -L <Размер в килобайтах> Имя файла
    Filename Chattr + C
     

    Совет: Резервное копирование с BSDTAR или TAR, копией с rsync или cp

Следующая тема Thine Thin Thin VS толстые густые LUN:

  • тонкие лунки, которые являются редкими

    , урезанные -S -S <размер в килобайтах>  имя файла
     

    Совет: Резервное копирование BSDTAR BSDTAR , копирование с CP

  • Толстые LUN ​​являются регулярными файлами с атрибутом + C (+ C, так что это делает его ни одной коровой, копировать Напишите, чтобы все пишеты, по сути, придерживаются того, куда его выделили, и никаких новых пишетов не происходит за этот файл, когда есть перезаписи или удаления - исследование BOW и BTRFS ). Вместо того, чтобы сделать файл с усечением, сделайте его с помощью «FALLACET -L»

     Touch Filename
    Fortocate -L <Размер в килобайтах> Имя файла
     

    Совет: Резервное копирование с BSDTAR или TAR, копированием с rsync или cp

Что такое толстый VS тонкий файл

  • толстые густые файлы / файлы, заполнить их данные от 0 до выделенного размера, метаданные притворяются, где 0s есть. Когда вы заполните данные, данные заполняют
  • густые LUN ​​/ файлы: заполните их данные в начале с 0s или что-то, что ленивый нулевой или не нулевой) - эти установленные бронирования (или как ZFS любят звонить в рефрижерациях)

Статья VMware здесь описывает ленивый против нулевого нуля, с толстыми LUN / файлами: https://communities.vmware.com/message/2199576

Совет

запомнить Толстые и тонкие не только применимы к LUN , он также может быть на файлах, файловые системы ZFS (акции / тома / LUN), и я уверен, что другие вещи (просто посмотрите на ZFS).

15
27.01.2020, 19:34

Из опыта (, хотя на Mac, который является системой на основе Unix ), bsdtarможет автоматически определять тип сжатия файла (при использовании в качестве bsdtar xf -), а tar/ gtarтребует, чтобы пользователь указал тип сжатия, присутствующий в файле

0
25.02.2021, 14:07

Теги

Похожие вопросы