Термин, использованный в спецификации POSIX date
команда является "спецификациями преобразования".
Строка формата для date
команда тесно основана на строке формата для C printf
функция; стандарт C также относится к вещам как %d
как "спецификации преобразования".
T
не предшествовавший %
просто символ: "Все другие символы должны быть скопированы в вывод без изменения".
Согласно разделу истории изменений описания POSIX date
:
ОПИСАНИЕ обновляется для обращения к спецификациям преобразования вместо полевых дескрипторов для непротиворечивости с категорией LC_TIME.
Таким образом, по-видимому, более ранняя версия спецификации использовала фразу "полевые дескрипторы", но "спецификации преобразования" текущий официальный термин.
Конечно, это не означает, что необходимо отослать к ним тот путь.
Вы против "размера блока" компрессора. Большинство программ сжатия разбивают входной сигнал на блоки и сжимают каждый блок. Похоже, что размер блока bzip увеличивается только до 900K, так что он не увидит шаблона, для повторения которого требуется больше 900K байт.
http://www.bzip.org/1.0.3/html/memory-management.html
gzip использует блоки 32K.
С xz вам повезло! Из man-страницы:
Preset DictSize CompCPU CompMem DecMem
-0 256 KiB 0 3 MiB 1 MiB
-1 1 MiB 1 9 MiB 2 MiB
-2 2 MiB 2 17 MiB 3 MiB
-3 4 MiB 3 32 MiB 5 MiB
-4 4 MiB 4 48 MiB 5 MiB
-5 8 MiB 5 94 MiB 9 MiB
-6 8 MiB 6 94 MiB 9 MiB
-7 16 MiB 6 186 MiB 17 MiB
-8 32 MiB 6 370 MiB 33 MiB
-9 64 MiB 6 674 MiB 65 MiB
так "xz -8" найдет до 32МБ паттернов, а "xz -9" до 64МБ паттернов. Но остерегайтесь, сколько тарана требуется для выполнения компрессии (и для распаковки)....
Выбранное вами случайное содержимое файла не является хорошим примером - сжатые файлы tar будут больше , чем оригиналы. Вы увидите то же самое с файлами в уже сжатых форматах (например, во многих форматах изображений / аудио / видео).
Но объединение нескольких файлов со сжимаемым содержимым обычно приводит к меньшему общему размеру tarfile, чем при их раздельном хранении, особенно когда содержимое одинаково (например, файлы журнала из одной и той же программы). Причина в том, что некоторые данные смещения сжатия для каждого файла (например, массивы шаблонов для некоторых алгоритмов сжатия) могут совместно использоваться всеми файлами в одном и том же tar-файле.
Как уже указывалось:
Лучшим тестовым примером может быть следующее:
cd /var/tmp
tar -zcf test1.tar /usr
tar -cf test2.tar /usr
gzip test2.tar
ls -h
(Примечание: надеемся, что в / usr
нет монтирования!)
Вы можете использовать tar -jcf
для xz вместо этого сжатие.
Теперь, если test2.tar.gz
меньше, чем test1.tar.gz, то тест успешен (т. Е. Архивирование файлов, тогда сжатие лучше, чем сжатие, а затем архивирование). Я предполагаю, что это будет для большого количества (то есть тысяч) файлов. Обратной стороной является то, что это потенциально может занять больше времени для выполнения, а также потребовать гораздо больше места на диске, поскольку сначала нужно создать весь tar-файл, а затем сжать его. Вот почему вместо этого часто используется 1-й метод, поскольку он сжимает каждый файл на лету, даже если он может не дать такой маленький архив.
Например, в нашем внешнем резервном копировании мы обычно создаем резервную копию 4 000 000 файлов общим объемом около 2 ТБ. Таким образом, первый метод намного быстрее и не требует дополнительных 2 ТБ на диске.