This manual is for Tarlz (version 0.19, 8 January 2021).
Copyright © 2013-2021 Antonio Diaz Diaz.
This manual is free documentation: you have unlimited permission to copy, distribute, and modify it.
Tarlz is a massively parallel (multi-threaded) combined implementation of the tar archiver and the lzip compressor. Tarlz uses the compression library lzlib.
Tarlz creates tar archives using a simplified and safer variant of the POSIX pax format compressed in lzip format, keeping the alignment between tar members and lzip members. 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.
Keeping the alignment between tar members and lzip members has two advantages. It adds an indexed lzip layer on top of the tar archive, making it possible to decode the archive safely in parallel. It also minimizes the amount of data lost in case of corruption. Compressing a tar archive with plzip may even double the amount of files lost for each lzip member damaged because it does not keep the members aligned.
Tarlz can create tar archives with five levels of compression granularity: per file (--no-solid), per block (--bsolid, default), per directory (--dsolid), appendable solid (--asolid), and solid (--solid). It can also create uncompressed tar archives.
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:
Tarlz protects the extended records with a Cyclic Redundancy Check (CRC) in a way compatible with standard tar tools. See crc32.
Tarlz does not understand other tar formats like 'gnu', 'oldgnu', 'star' or 'v7'. The command 'tarlz -tf archive.tar.lz > /dev/null' can be used to verify that the format of the archive is compatible with tarlz.
The format for running tarlz is:
tarlz [options] [files]
All operations except '--concatenate' operate on whole trees if any file is a directory.
On archive creation or appending tarlz archives the files specified, but removes from member names any leading and trailing slashes and any file name prefixes containing a '..' component. On extraction, leading and trailing slashes are also removed from member names, and archive members containing a '..' component in the file name 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:
--help-V--version-A--concatenate-B bytes--data-size=bytes-c--create-C dir--directory=dirNote 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 file name in the command line.
-d--diffAs tarlz removes leading slashes from member names, the option '-C' may
be used in combination with '--diff' when absolute file names were used
on archive creation: 'tarlz -C / -d'. Alternatively, tarlz may be
run from the root directory to perform the comparison.
--ignore-ids--deleteTo delete a directory without deleting the files under it, use
'tarlz --delete -f foo --exclude='dir/*' dir'. Deleting in place
may be dangerous. A corrupt archive, a power cut, or an I/O error may cause
data loss.
--exclude=pattern-f archive--file=archive-h--dereference--mtime=date-n n--threads=nNote that the number of usable threads is limited during compression to
ceil( uncompressed_size / data_size ) (see 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'.
-p--preserve-permissions-q--quiet-r--append-t--list-v--verbose-x--extract-0 .. -9| 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--asolid--bsolid--dsolid--no-solid--solid--anonymous--owner=owner--group=group--keep-damaged--missing-crc--out-slots=n--check-libExit status: 0 for a normal exit, 1 for environmental problems (file not found, files differ, 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.
The set of characters from which portable file names are constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
The last three characters are the period, underscore, and hyphen-minus characters, respectively.
File names are identifiers. Therefore, archiving works better when file names use only the portable character set without spaces added.
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:
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. See Multi-threaded decoding.
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:
tar +========+======+=================+===============+========+======+========+ | header | data | extended header | extended data | header | data | EOF | +========+======+=================+===============+========+======+========+ tar.lz +===============+=================================================+========+ | member | member | member | +===============+=================================================+========+
The pax header block is identical to the ustar header block described below except that the typeflag has the value 'x' (extended). The field 'size' 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. See 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 fields <length> and <keyword> in the record must be limited to the portable character set (see Portable character set). The field <length> contains the decimal length of the record in bytes, including the trailing newline. The field <value> is stored as-is, without conversion to UTF-8 nor any other transformation. The fields are separated by the ASCII characters space, equal-sign, and newline.
These are the <keyword> values currently supported by tarlz:
linkpathpathsizeGNU.crc32At verbosity level 1 or higher tarlz prints a diagnostic for each unknown extended header keyword found in an archive, once per keyword.
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 character set (see Portable character set), but if an implementation supports the use of characters outside of '/' and the portable 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 fields 'prefix' and 'name' 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 field 'linkname' 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 field 'mode' 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 fields 'uid' and 'gid' are the user and group IDs of the owner and group of the file, respectively.
The field 'size' contains the octal representation of the size of the file in bytes. If the field 'typeflag' 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 field 'mtime' contains the octal representation of the modification time of the file at the time it was archived, obtained from the function 'stat'.
The field 'chksum' 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 field 'typeflag' contains a single character specifying the type of file archived:
'0''1''2''3', '4''5''6''7'The field 'magic' contains the ASCII null-terminated string "ustar". The field 'version' 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 longer than standard ustar by not requiring a terminating null character.
Tarlz creates safe archives that allow the reliable detection of invalid or corrupt metadata during decoding even when the integrity checking of lzip can't be used because the lzip members are only decompressed partially, as it happens in parallel '--diff', '--list', and '--extract'. In order to achieve this goal, 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.
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 file name 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 file name 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 and archiver misbehavior more probable.
Headers and metadata must be protected separately from data because the integrity checking of lzip may not be able to detect the corruption before the metadata has been used, for example, to create a new file in the wrong place.
Because of the above, tarlz protects the extended records with a CRC in a way compatible with standard tar tools. See key_crc32.
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 file name, the fields 'prefix' and 'name' 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 file names, perhaps overwriting existing files or directories. It may be a security risk to extract a file with a truncated file name.
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 file name also to the extended header to prevent an ustar tool from trying to extract the file or link. This also makes easier during parallel decoding the detection of a tar member split between two lzip members at the boundary between the extended header and the ustar header.
The tarlz format is mainly ustar. Extended pax headers are used only when needed because the length of a file name or link name, or the size of a file exceed the limits of the ustar format. Adding 1 KiB of extended headers to each member just to record subsecond timestamps seems wasteful for a backup format. Moreover, minimizing the overhead may help recovering the archive with lziprecover in case of corruption.
Global pax headers are tolerated, but not supported; they are parsed and ignored. Some operations may not behave as expected if the archive contains global headers.
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.
The parts of tarlz related to sequential processing of the archive are more or less similar to any other tar and won't be described here. The interesting parts described here are those related to Multi-threaded processing.
The structure of the part of tarlz performing Multi-threaded archive creation is somewhat similar to that of plzip with the added complication of the solidity levels. A grouper thread and several worker threads are created, acting the main thread as muxer (multiplexer) thread. A "packet courier" takes care of data transfers among threads and limits the maximum number of data blocks (packets) being processed simultaneously.
The grouper traverses the directory tree, groups together the metadata of the files to be archived in each lzip member, and distributes them to the workers. The workers compress the metadata received from the grouper along with the file data read from the file system. The muxer collects processed packets from the workers, and writes them to the archive.
,--------,
| data|---> to each worker below
| | ,------------,
| file | ,-->| worker 0 |--,
| system | | `------------' |
| | ,---------, | ,------------, | ,-------, ,---------,
|metadata|--->| grouper |-+-->| worker 1 |--+-->| muxer |-->| archive |
`--------' `---------' | `------------' | `-------' `---------'
| ... |
| ,------------, |
`-->| worker N-1 |--'
`------------'
Decoding an archive is somewhat similar to how plzip decompresses a regular file to standard output, with the differences that it is not the data but only messages what is written to stdout/stderr, and that each worker may access files in the file system either to read them (diff) or write them (extract). As in plzip, each worker reads members directly from the archive.
,--------,
| file |<---> data to/from each worker below
| system |
`--------' ,------------,
,-->| worker 0 |--,
| `------------' |
,---------, | ,------------, | ,-------, ,--------,
| archive |-+-->| worker 1 |--+-->| muxer |-->| stdout |
`---------' | `------------' | `-------' | stderr |
| ... | `--------'
| ,------------, |
`-->| worker N-1 |--'
`------------'
As misaligned tar.lz archives can't be decoded in parallel, and the misalignment can't be detected until after decoding has started, a "mastership request" mechanism has been designed that allows the decoding to continue instead of signalling an error.
During parallel decoding, if a worker finds a misalignment, it requests mastership to decode the rest of the archive. When mastership is requested, an error_member_id is set, and all subsequently received packets with member_id > error_member_id are rejected. All workers requesting mastership are blocked at the request_mastership call until mastership is granted. Mastership is granted to the delivering worker when its queue is empty to make sure that all preceding packets have been processed. When mastership is granted, all packets are deleted and all subsequently received packets not coming from the master are rejected.
If a worker can't continue decoding for any cause (for example lack of memory or finding a split tar member at the beginning of a lzip member), it requests mastership to print an error and terminate the program. Only if some other worker requests mastership in a previous lzip member can this error be avoided.
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.
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)
On the other hand, multi-threaded '--list' won't detect corruption in the tar member data because it only decodes the part of each lzip member corresponding to the tar member header. This is another reason why the tar headers must provide its own integrity checking.
Multi-threaded extraction may produce different output than single-threaded extraction in some cases:
During multi-threaded extraction, several independent processes are simultaneously reading the archive and creating files in the file system. The archive is not read sequentially. As a consequence, any error or weirdness in the archive (like a corrupt member or an EOF block in the middle of the archive) won't be usually detected until part of the archive beyond that point has been processed.
If the archive contains two or more tar members with the same name, single-threaded extraction extracts the members in the order they appear in the archive and leaves in the file system the last version of the file. But multi-threaded extraction may extract the members in any order and leave in the file system any version of the file nondeterministically. It is unspecified which of the tar members is extracted.
If the same file is extracted through several paths (different member names resolve to the same file in the file system), the result is undefined. (Probably the resulting file will be mangled).
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 (see --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 archive 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 14 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
|
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', and the whole tree under directory 'dir1' from archive 'archive.tar.lz'.
tarlz -xf archive.tar.lz a c dir1
Example 8: Copy the contents of directory 'sourcedir' to the directory 'destdir'.
tarlz -C sourcedir -c . | tarlz -C destdir -x
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'.