path: root/doc/tarlz.info

This is tarlz.info, produced by makeinfo version 4.13+ from tarlz.texi.

INFO-DIR-SECTION Data Compression
START-INFO-DIR-ENTRY
* Tarlz: (tarlz).               Archiver with multimember lzip compression
END-INFO-DIR-ENTRY


File: tarlz.info,  Node: Top,  Next: Introduction,  Up: (dir)

Tarlz Manual
************

This manual is for Tarlz (version 0.13, 27 February 2019).

* Menu:

* Introduction::              Purpose and features of tarlz
* Invoking tarlz::            Command line interface
* File format::               Detailed format of the compressed archive
* Amendments to pax format::  The reasons for the differences with pax
* Multi-threaded tar::        Limitations of parallel tar decoding
* Minimum archive sizes::     Sizes required for full multi-threaded speed
* Examples::                  A small tutorial with examples
* Problems::                  Reporting bugs
* Concept index::             Index of concepts


   Copyright (C) 2013-2019 Antonio Diaz Diaz.

   This manual is free documentation: you have unlimited permission to
copy, distribute and modify it.


File: tarlz.info,  Node: Introduction,  Next: Invoking tarlz,  Prev: Top,  Up: Top

1 Introduction
**************

Tarlz is a massively parallel (multi-threaded) combined implementation
of the tar archiver and the lzip compressor. Tarlz creates, lists and
extracts archives in a simplified posix pax format compressed with
lzip, keeping the alignment between tar members and lzip members. This
method adds an indexed lzip layer on top of the tar archive, making it
possible to decode the archive safely in parallel. The resulting
multimember tar.lz archive is fully backward compatible with standard
tar tools like GNU tar, which treat it like any other tar.lz archive.
Tarlz can append files to the end of such compressed archives.

   Tarlz can create tar archives with five levels of compression
granularity; per file, per block (default), per directory, appendable
solid, and solid.

Of course, compressing each file (or each directory) individually can't
achieve a compression ratio as high as compressing solidly the whole tar
archive, but it has the following advantages:

   * The resulting multimember tar.lz archive can be decompressed in
     parallel, multiplying the decompression speed.

   * New members can be appended to the archive (by removing the EOF
     member) just like to an uncompressed tar archive.

   * It is a safe posix-style backup format. In case of corruption,
     tarlz can extract all the undamaged members from the tar.lz
     archive, skipping over the damaged members, just like the standard
     (uncompressed) tar. Moreover, the option '--keep-damaged' can be
     used to recover as much data as possible from each damaged member,
     and lziprecover can be used to recover some of the damaged members.

   * A multimember tar.lz archive is usually smaller than the
     corresponding solidly compressed tar.gz archive, except when
     individually compressing files smaller than about 32 KiB.

   Tarlz protects the extended records with a CRC in a way compatible
with standard tar tools. *Note crc32::.

   Tarlz does not understand other tar formats like 'gnu', 'oldgnu',
'star' or 'v7'.


File: tarlz.info,  Node: Invoking tarlz,  Next: File format,  Prev: Introduction,  Up: Top

2 Invoking tarlz
****************

The format for running tarlz is:

     tarlz [OPTIONS] [FILES]

On archive creation or appending tarlz archives the files specified, but
removes from member names any leading and trailing slashes and any
filename prefixes containing a '..' component. On extraction, leading
and trailing slashes are also removed from member names, and archive
members containing a '..' component in the filename are skipped. Tarlz
detects when the archive being created or enlarged is among the files
to be dumped, appended or concatenated, and skips it.

   On extraction and listing, tarlz removes leading './' strings from
member names in the archive or given in the command line, so that
'tarlz -xf foo ./bar baz' extracts members 'bar' and './baz' from
archive 'foo'.

   If several compression levels or '--*solid' options are given, the
last setting is used. For example '-9 --solid --uncompressed -1' is
equivalent to '-1 --solid'

   tarlz supports the following options:

'-h'
'--help'
     Print an informative help message describing the options and exit.

'-V'
'--version'
     Print the version number of tarlz on the standard output and exit.
     This version number should be included in all bug reports.

'-A'
'--concatenate'
     Append tar.lz archives to the end of a tar.lz archive. All the
     archives involved must be regular (seekable) files compressed as
     multimember lzip files, and the two end-of-file blocks plus any
     zero padding must be contained in the last lzip member of each
     archive. The intermediate end-of-file blocks are removed as each
     new archive is concatenated. Exit with status 0 without modifying
     the archive if no FILES have been specified. Tarlz can't
     concatenate uncompressed tar archives.

'-B BYTES'
'--data-size=BYTES'
     Set target size of input data blocks for the '--bsolid' option.
     *Note --bsolid::. Valid values range from 8 KiB to 1 GiB. Default
     value is two times the dictionary size, except for option '-0'
     where it defaults to 1 MiB. *Note Minimum archive sizes::.

'-c'
'--create'
     Create a new archive from FILES.

'-C DIR'
'--directory=DIR'
     Change to directory DIR. When creating or appending, the position
     of each '-C' option in the command line is significant; it will
     change the current working directory for the following FILES until
     a new '-C' option appears in the command line. When extracting, all
     the '-C' options are executed in sequence before starting the
     extraction. Listing ignores any '-C' options specified. DIR is
     relative to the then current working directory, perhaps changed by
     a previous '-C' option.

     Note that a process can only have one current working directory
     (CWD).  Therefore multi-threading can't be used to create an
     archive if a '-C' option appears after a relative filename in the
     command line.

'-d'
'--diff'
     Find differences between archive and file system. For each tar
     member in the archive, verify that the corresponding file exists
     and is of the same type (regular file, directory, etc). Report the
     differences found in type, mode (permissions), owner and group
     IDs, modification time, file size, file contents (of regular
     files), target (of symlinks) and device number (of block/character
     special files).

'--ignore-ids'
     Make '--diff' ignore differences in owner and group IDs. This
     option is useful when comparing an '--anonymous' archive.

'-f ARCHIVE'
'--file=ARCHIVE'
     Use archive file ARCHIVE. '-' used as an ARCHIVE argument reads
     from standard input or writes to standard output.

'-n N'
'--threads=N'
     Set the number of (de)compression threads, overriding the system's
     default.  Valid values range from 0 to "as many as your system can
     support". A value of 0 disables threads entirely. If this option
     is not used, tarlz tries to detect the number of processors in the
     system and use it as default value.  'tarlz --help' shows the
     system's default value. See the note about multi-threaded archive
     creation in the '-C' option above.  Multi-threaded extraction of
     files from an archive is not yet implemented.  *Note
     Multi-threaded tar::.

     Note that the number of usable threads is limited during
     compression to ceil( uncompressed_size / data_size ) (*note
     Minimum archive sizes::), and during decompression to the number
     of lzip members in the tar.lz archive, which you can find by
     running 'lzip -lv archive.tar.lz'.

'-q'
'--quiet'
     Quiet operation. Suppress all messages.

'-r'
'--append'
     Append files to the end of a tar.lz archive. The archive must be a
     regular (seekable) file compressed as a multimember lzip file, and
     the two end-of-file blocks plus any zero padding must be contained
     in the last lzip member of the archive. First this last member is
     removed, then the new members are appended, and then a new
     end-of-file member is appended to the archive. Exit with status 0
     without modifying the archive if no FILES have been specified.
     Tarlz can't append files to an uncompressed tar archive.

'-t'
'--list'
     List the contents of an archive. If FILES are given, list only the
     FILES given.

'-v'
'--verbose'
     Verbosely list files processed.

'-x'
'--extract'
     Extract files from an archive. If FILES are given, extract only
     the FILES given. Else extract all the files in the archive.

'-0 .. -9'
     Set the compression level. The default compression level is '-6'.
     Like lzip, tarlz also minimizes the dictionary size of the lzip
     members it creates, reducing the amount of memory required for
     decompression.

     Level   Dictionary size   Match length limit
     -0      64 KiB            16 bytes
     -1      1 MiB             5 bytes
     -2      1.5 MiB           6 bytes
     -3      2 MiB             8 bytes
     -4      3 MiB             12 bytes
     -5      4 MiB             20 bytes
     -6      8 MiB             36 bytes
     -7      16 MiB            68 bytes
     -8      24 MiB            132 bytes
     -9      32 MiB            273 bytes

'--uncompressed'
     With '--create', don't compress the created tar archive. Create an
     uncompressed tar archive instead.

'--asolid'
     When creating or appending to a compressed archive, use appendable
     solid compression. All the files being added to the archive are
     compressed into a single lzip member, but the end-of-file blocks
     are compressed into a separate lzip member. This creates a solidly
     compressed appendable archive.  Solid archives can't be created
     nor decoded in parallel.

'--bsolid'
     When creating or appending to a compressed archive, use block
     compression.  Tar members are compressed together in a lzip member
     until they approximate a target uncompressed size. The size can't
     be exact because each solidly compressed data block must contain
     an integer number of tar members. Block compression is the default
     because it improves compression ratio for archives with many files
     smaller than the block size. This option allows tarlz revert to
     default behavior if, for example, it is invoked through an alias
     like 'tar='tarlz --solid''. *Note --data-size::, to set the target
     block size.

'--dsolid'
     When creating or appending to a compressed archive, compress each
     file specified in the command line separately in its own lzip
     member, and use solid compression for each directory specified in
     the command line. The end-of-file blocks are compressed into a
     separate lzip member. This creates a compressed appendable archive
     with a separate lzip member for each file or top-level directory
     specified.

'--no-solid'
     When creating or appending to a compressed archive, compress each
     file separately in its own lzip member. The end-of-file blocks are
     compressed into a separate lzip member. This creates a compressed
     appendable archive with a lzip member for each file.

'--solid'
     When creating or appending to a compressed archive, use solid
     compression.  The files being added to the archive, along with the
     end-of-file blocks, are compressed into a single lzip member. The
     resulting archive is not appendable. No more files can be later
     appended to the archive. Solid archives can't be created nor
     decoded in parallel.

'--anonymous'
     Equivalent to '--owner=root --group=root'.

'--owner=OWNER'
     When creating or appending, use OWNER for files added to the
     archive. If OWNER is not a valid user name, it is decoded as a
     decimal numeric user ID.

'--group=GROUP'
     When creating or appending, use GROUP for files added to the
     archive. If GROUP is not a valid group name, it is decoded as a
     decimal numeric group ID.

'--keep-damaged'
     Don't delete partially extracted files. If a decompression error
     happens while extracting a file, keep the partial data extracted.
     Use this option to recover as much data as possible from each
     damaged member.

'--missing-crc'
     Exit with error status 2 if the CRC of the extended records is
     missing.  When this option is used, tarlz detects any corruption
     in the extended records (only limited by CRC collisions). But note
     that a corrupt 'GNU.crc32' keyword, for example 'GNU.crc33', is
     reported as a missing CRC instead of as a corrupt record. This
     misleading 'Missing CRC' message is the consequence of a flaw in
     the posix pax format; i.e., the lack of a mandatory check sequence
     in the extended records. *Note crc32::.


   Exit status: 0 for a normal exit, 1 for environmental problems (file
not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or
invalid input file, 3 for an internal consistency error (eg, bug) which
caused tarlz to panic.


File: tarlz.info,  Node: File format,  Next: Amendments to pax format,  Prev: Invoking tarlz,  Up: Top

3 File format
*************

In the diagram below, a box like this:
+---+
|   | <-- the vertical bars might be missing
+---+

   represents one byte; a box like this:
+==============+
|              |
+==============+

   represents a variable number of bytes or a fixed but large number of
bytes (for example 512).


   A tar.lz file consists of a series of lzip members (compressed data
sets).  The members simply appear one after another in the file, with no
additional information before, between, or after them.

   Each lzip member contains one or more tar members in a simplified
posix pax interchange format; the only pax typeflag value supported by
tarlz (in addition to the typeflag values defined by the ustar format)
is 'x'. The pax format is an extension on top of the ustar format that
removes the size limitations of the ustar format.

   Each tar member contains one file archived, and is represented by the
following sequence:

   * An optional extended header block with extended header records.
     This header block is of the form described in pax header block,
     with a typeflag value of 'x'. The extended header records are
     included as the data for this header block.

   * A header block in ustar format that describes the file. Any fields
     defined in the preceding optional extended header records override
     the associated fields in this header block for this file.

   * Zero or more blocks that contain the contents of the file.

   Each tar member must be contiguously stored in a lzip member for the
parallel decoding operations like '--list' to work. If any tar member
is split over two or more lzip members, the archive must be decoded
sequentially. *Note Multi-threaded tar::.

   At the end of the archive file there are two 512-byte blocks filled
with binary zeros, interpreted as an end-of-archive indicator. These EOF
blocks are either compressed in a separate lzip member or compressed
along with the tar members contained in the last lzip member.

   The diagram below shows the correspondence between each tar member
(formed by one or two headers plus optional data) in the tar archive
and each lzip member in the resulting multimember tar.lz archive, when
per file compression is used: *Note File format: (lzip)File format.

tar
+========+======+=================+===============+========+======+========+
| header | data | extended header | extended data | header | data |   EOF  |
+========+======+=================+===============+========+======+========+

tar.lz
+===============+=================================================+========+
|     member    |                      member                     | member |
+===============+=================================================+========+


3.1 Pax header block
====================

The pax header block is identical to the ustar header block described
below except that the typeflag has the value 'x' (extended). The size
field is the size of the extended header data in bytes. Most other
fields in the pax header block are zeroed on archive creation to
prevent trouble if the archive is read by an ustar tool, and are
ignored by tarlz on archive extraction. *Note flawed-compat::.

   The pax extended header data consists of one or more records, each of
them constructed as follows:
'"%d %s=%s\n", <length>, <keyword>, <value>'

   The <length>, <blank>, <keyword>, <equals-sign>, and <newline> in the
record must be limited to the portable character set. The <length> field
contains the decimal length of the record in bytes, including the
trailing <newline>. The <value> field is stored as-is, without
conversion to UTF-8 nor any other transformation.

   These are the <keyword> fields currently supported by tarlz:

'linkpath'
     The pathname of a link being created to another file, of any type,
     previously archived. This record overrides the linkname field in
     the following ustar header block. The following ustar header block
     determines the type of link created. If typeflag of the following
     header block is 1, it will be a hard link. If typeflag is 2, it
     will be a symbolic link and the linkpath value will be used as the
     contents of the symbolic link.

'path'
     The pathname of the following file. This record overrides the name
     and prefix fields in the following ustar header block.

'size'
     The size of the file in bytes, expressed as a decimal number using
     digits from the ISO/IEC 646:1991 (ASCII) standard. This record
     overrides the size field in the following ustar header block. The
     size record is used only for files with a size value greater than
     8_589_934_591 (octal 77777777777). This is 2^33 bytes or larger.

'GNU.crc32'
     CRC32-C (Castagnoli) of the extended header data excluding the 8
     bytes representing the CRC <value> itself. The <value> is
     represented as 8 hexadecimal digits in big endian order,
     '22 GNU.crc32=00000000\n'. The keyword of the CRC record is
     protected by the CRC to guarante that corruption is always detected
     (except in case of CRC collision). A CRC was chosen because a
     checksum is too weak for a potentially large list of variable
     sized records. A checksum can't detect simple errors like the
     swapping of two bytes.


3.2 Ustar header block
======================

The ustar header block has a length of 512 bytes and is structured as
shown in the following table. All lengths and offsets are in decimal.

Field Name   Offset   Length (in bytes)
name         0        100
mode         100      8
uid          108      8
gid          116      8
size         124      12
mtime        136      12
chksum       148      8
typeflag     156      1
linkname     157      100
magic        257      6
version      263      2
uname        265      32
gname        297      32
devmajor     329      8
devminor     337      8
prefix       345      155

   All characters in the header block are coded using the ISO/IEC
646:1991 (ASCII) standard, except in fields storing names for files,
users, and groups. For maximum portability between implementations,
names should only contain characters from the portable filename
character set. But if an implementation supports the use of characters
outside of '/' and the portable filename character set in names for
files, users, and groups, tarlz will use the byte values in these names
unmodified.

   The fields name, linkname, and prefix are null-terminated character
strings except when all characters in the array contain non-null
characters including the last character.

   The name and the prefix fields produce the pathname of the file. A
new pathname is formed, if prefix is not an empty string (its first
character is not null), by concatenating prefix (up to the first null
character), a <slash> character, and name; otherwise, name is used
alone. In either case, name is terminated at the first null character.
If prefix begins with a null character, it is ignored. In this manner,
pathnames of at most 256 characters can be supported. If a pathname does
not fit in the space provided, an extended record is used to store the
pathname.

   The linkname field does not use the prefix to produce a pathname. If
the linkname does not fit in the 100 characters provided, an extended
record is used to store the linkname.

   The mode field provides 12 access permission bits. The following
table shows the symbolic name of each bit and its octal value:

Bit Name   Value   Bit Name   Value   Bit Name   Value
---------------------------------------------------
S_ISUID    04000   S_ISGID    02000   S_ISVTX    01000
S_IRUSR    00400   S_IWUSR    00200   S_IXUSR    00100
S_IRGRP    00040   S_IWGRP    00020   S_IXGRP    00010
S_IROTH    00004   S_IWOTH    00002   S_IXOTH    00001

   The uid and gid fields are the user and group ID of the owner and
group of the file, respectively.

   The size field contains the octal representation of the size of the
file in bytes. If the typeflag field specifies a file of type '0'
(regular file) or '7' (high performance regular file), the number of
logical records following the header is (size / 512) rounded to the next
integer. For all other values of typeflag, tarlz either sets the size
field to 0 or ignores it, and does not store or expect any logical
records following the header. If the file size is larger than
8_589_934_591 bytes (octal 77777777777), an extended record is used to
store the file size.

   The mtime field contains the octal representation of the modification
time of the file at the time it was archived, obtained from the stat()
function.

   The chksum field contains the octal representation of the value of
the simple sum of all bytes in the header logical record. Each byte in
the header is treated as an unsigned value. When calculating the
checksum, the chksum field is treated as if it were all <space>
characters.

   The typeflag field contains a single character specifying the type of
file archived:

''0''
     Regular file.

''1''
     Hard link to another file, of any type, previously archived.

''2''
     Symbolic link.

''3', '4''
     Character special file and block special file respectively. In
     this case the devmajor and devminor fields contain information
     defining the device in unspecified format.

''5''
     Directory.

''6''
     FIFO special file.

''7''
     Reserved to represent a file to which an implementation has
     associated some high-performance attribute. Tarlz treats this type
     of file as a regular file (type 0).


   The magic field contains the ASCII null-terminated string "ustar".
The version field contains the characters "00" (0x30,0x30). The fields
uname, and gname are null-terminated character strings except when all
characters in the array contain non-null characters including the last
character. Each numeric field contains a leading space- or zero-filled,
optionally null-terminated octal number using digits from the ISO/IEC
646:1991 (ASCII) standard. Tarlz is able to decode numeric fields 1
byte larger than standard ustar by not requiring a terminating null
character.


File: tarlz.info,  Node: Amendments to pax format,  Next: Multi-threaded tar,  Prev: File format,  Up: Top

4 The reasons for the differences with pax
******************************************

Tarlz is meant to reliably detect invalid or corrupt metadata during
extraction and to not create safety risks in the archives it creates. In
order to achieve these goals, tarlz makes some changes to the variant
of the pax format that it uses. This chapter describes these changes
and the concrete reasons to implement them.


4.1 Add a CRC of the extended records
=====================================

The posix pax format has a serious flaw. The metadata stored in pax
extended records are not protected by any kind of check sequence.
Corruption in a long filename may cause the extraction of the file in
the wrong place without warning. Corruption in a large file size may
cause the truncation of the file or the appending of garbage to the
file, both followed by a spurious warning about a corrupt header far
from the place of the undetected corruption.

   Metadata like filename and file size must be always protected in an
archive format because of the adverse effects of undetected corruption
in them, potentially much worse that undetected corruption in the data.
Even more so in the case of pax because the amount of metadata it
stores is potentially large, making undetected corruption more probable.

   Because of the above, tarlz protects the extended records with a CRC
in a way compatible with standard tar tools. *Note key_crc32::.


4.2 Remove flawed backward compatibility
========================================

In order to allow the extraction of pax archives by a tar utility
conforming to the POSIX-2:1993 standard, POSIX.1-2008 recommends
selecting extended header field values that allow such tar to create a
regular file containing the extended header records as data. This
approach is broken because if the extended header is needed because of
a long filename, the name and prefix fields will be unable to contain
the full pathname of the file. Therefore the files corresponding to
both the extended header and the overridden ustar header will be
extracted using truncated filenames, perhaps overwriting existing files
or directories. It may be a security risk to extract a file with a
truncated filename.

   To avoid this problem, tarlz writes extended headers with all fields
zeroed except size, chksum, typeflag, magic and version. This prevents
old tar programs from extracting the extended records as a file in the
wrong place.  Tarlz also sets to zero those fields of the ustar header
overridden by extended records.

   If an extended header is required for any reason (for example a file
size larger than 8 GiB or a link name longer than 100 bytes), tarlz
moves the filename also to the extended header to prevent an ustar tool
from trying to extract the file or link. This also makes easier during
parallel extraction or listing the detection of a tar member split
between two lzip members at the boundary between the extended header
and the ustar header.


4.3 As simple as possible (but not simpler)
===========================================

The tarlz format is mainly ustar. Extended pax headers are used only
when needed because the length of a filename or link name, or the size
of a file exceed the limits of the ustar format. Adding extended
headers to each member just to record subsecond timestamps seems
wasteful for a backup format.


4.4 Avoid misconversions to/from UTF-8
======================================

There is no portable way to tell what charset a text string is coded
into.  Therefore, tarlz stores all fields representing text strings
unmodified, without conversion to UTF-8 nor any other transformation.
This prevents accidental double UTF-8 conversions. If the need arises
this behavior will be adjusted with a command line option in the future.


File: tarlz.info,  Node: Multi-threaded tar,  Next: Minimum archive sizes,  Prev: Amendments to pax format,  Up: Top

5 Limitations of parallel tar decoding
**************************************

Safely decoding an arbitrary tar archive in parallel is impossible. For
example, if a tar archive containing another tar archive is decoded
starting from some position other than the beginning, there is no way
to know if the first header found there belongs to the outer tar
archive or to the inner tar archive. Tar is a format inherently serial;
it was designed for tapes.

   In the case of compressed tar archives, the start of each compressed
block determines one point through which the tar archive can be decoded
in parallel. Therefore, in tar.lz archives the decoding operations
can't be parallelized if the tar members are not aligned with the lzip
members. Tar archives compressed with plzip can't be decoded in
parallel because tar and plzip do not have a way to align both sets of
members. Certainly one can decompress one such archive with a
multi-threaded tool like plzip, but the increase in speed is not as
large as it could be because plzip must serialize the decompressed data
and pass them to tar, which decodes them sequentially, one tar member
at a time.

   On the other hand, if the tar.lz archive is created with a tool like
tarlz, which can guarantee the alignment between tar members and lzip
members because it controls both archiving and compression, then the
lzip format becomes an indexed layer on top of the tar archive which
makes possible decoding it safely in parallel.

   Tarlz is able to automatically decode aligned and unaligned
multimember tar.lz archives, keeping backwards compatibility. If tarlz
finds a member misalignment during multi-threaded decoding, it switches
to single-threaded mode and continues decoding the archive. Currently
only the '--list' option is able to do multi-threaded decoding.

   If the files in the archive are large, multi-threaded '--list' on a
regular (seekable) tar.lz archive can be hundreds of times faster than
sequential '--list' because, in addition to using several processors,
it only needs to decompress part of each lzip member. See the following
example listing the Silesia corpus on a dual core machine:

     tarlz -9 --no-solid -cf silesia.tar.lz silesia
     time lzip -cd silesia.tar.lz | tar -tf -            (5.032s)
     time plzip -cd silesia.tar.lz | tar -tf -           (3.256s)
     time tarlz -tf silesia.tar.lz                       (0.020s)


File: tarlz.info,  Node: Minimum archive sizes,  Next: Examples,  Prev: Multi-threaded tar,  Up: Top

6 Minimum archive sizes required for multi-threaded block compression
*********************************************************************

When creating or appending to a compressed archive using multi-threaded
block compression, tarlz puts tar members together in blocks and
compresses as many blocks simultaneously as worker threads are chosen,
creating a multimember compressed archive.

   For this to work as expected (and roughly multiply the compression
speed by the number of available processors), the uncompressed archive
must be at least as large as the number of worker threads times the
block size (*note --data-size::). Else some processors will not get any
data to compress, and compression will be proportionally slower. The
maximum speed increase achievable on a given file is limited by the
ratio (uncompressed_size / data_size). For example, a tarball the size
of gcc or linux will scale up to 10 or 12 processors at level -9.

   The following table shows the minimum uncompressed archive size
needed for full use of N processors at a given compression level, using
the default data size for each level:

Processors   2         4         8         16        64        256
------------------------------------------------------------------
Level                                                          
-0           2 MiB     4 MiB     8 MiB     16 MiB    64 MiB    256 MiB
-1           4 MiB     8 MiB     16 MiB    32 MiB    128 MiB   512 MiB
-2           6 MiB     12 MiB    24 MiB    48 MiB    192 MiB   768 MiB
-3           8 MiB     16 MiB    32 MiB    64 MiB    256 MiB   1 GiB
-4           12 MiB    24 MiB    48 MiB    96 MiB    384 MiB   1.5 GiB
-5           16 MiB    32 MiB    64 MiB    128 MiB   512 MiB   2 GiB
-6           32 MiB    64 MiB    128 MiB   256 MiB   1 GiB     4 GiB
-7           64 MiB    128 MiB   256 MiB   512 MiB   2 GiB     8 GiB
-8           96 MiB    192 MiB   384 MiB   768 MiB   3 GiB     12 GiB
-9           128 MiB   256 MiB   512 MiB   1 GiB     4 GiB     16 GiB


File: tarlz.info,  Node: Examples,  Next: Problems,  Prev: Minimum archive sizes,  Up: Top

7 A small tutorial with examples
********************************

Example 1: Create a multimember compressed archive 'archive.tar.lz'
containing files 'a', 'b' and 'c'.

     tarlz -cf archive.tar.lz a b c


Example 2: Append files 'd' and 'e' to the multimember compressed
archive 'archive.tar.lz'.

     tarlz -rf archive.tar.lz d e


Example 3: Create a solidly compressed appendable archive
'archive.tar.lz' containing files 'a', 'b' and 'c'.  Then append files
'd' and 'e' to the archive.

     tarlz --asolid -cf archive.tar.lz a b c
     tarlz --asolid -rf archive.tar.lz d e


Example 4: Create a compressed appendable archive containing directories
'dir1', 'dir2' and 'dir3' with a separate lzip member per directory.
Then append files 'a', 'b', 'c', 'd' and 'e' to the archive, all of
them contained in a single lzip member.  The resulting archive
'archive.tar.lz' contains 5 lzip members (including the EOF member).

     tarlz --dsolid -cf archive.tar.lz dir1 dir2 dir3
     tarlz --asolid -rf archive.tar.lz a b c d e


Example 5: Create a solidly compressed archive 'archive.tar.lz'
containing files 'a', 'b' and 'c'. Note that no more files can be later
appended to the archive.

     tarlz --solid -cf archive.tar.lz a b c


Example 6: Extract all files from archive 'archive.tar.lz'.

     tarlz -xf archive.tar.lz


Example 7: Extract files 'a' and 'c' from archive 'archive.tar.lz'.

     tarlz -xf archive.tar.lz a c


Example 8: Copy the contents of directory 'sourcedir' to the directory
'destdir'.

     tarlz -C sourcedir -c . | tarlz -C destdir -x


File: tarlz.info,  Node: Problems,  Next: Concept index,  Prev: Examples,  Up: Top

8 Reporting bugs
****************

There are probably bugs in tarlz. There are certainly errors and
omissions in this manual. If you report them, they will get fixed. If
you don't, no one will ever know about them and they will remain unfixed
for all eternity, if not longer.

   If you find a bug in tarlz, please send electronic mail to
<lzip-bug@nongnu.org>. Include the version number, which you can find
by running 'tarlz --version'.


File: tarlz.info,  Node: Concept index,  Prev: Problems,  Up: Top

Concept index
*************

[index]
* Menu:

* Amendments to pax format:              Amendments to pax format.
                                                                (line 6)
* bugs:                                  Problems.              (line 6)
* examples:                              Examples.              (line 6)
* file format:                           File format.           (line 6)
* getting help:                          Problems.              (line 6)
* introduction:                          Introduction.          (line 6)
* invoking:                              Invoking tarlz.        (line 6)
* minimum archive sizes:                 Minimum archive sizes. (line 6)
* options:                               Invoking tarlz.        (line 6)
* usage:                                 Invoking tarlz.        (line 6)
* version:                               Invoking tarlz.        (line 6)



Tag Table:
Node: Top223
Node: Introduction1089
Node: Invoking tarlz3228
Ref: --data-size5107
Ref: --bsolid10054
Node: File format13298
Ref: key_crc3218118
Node: Amendments to pax format23535
Ref: crc3224059
Ref: flawed-compat25084
Node: Multi-threaded tar27451
Node: Minimum archive sizes29990
Node: Examples32120
Node: Problems33789
Node: Concept index34315

End Tag Table


Local Variables:
coding: iso-8859-15
End: