Your browser sucks, JavaScript disabled! Gunnar's console needs JavaScript and WebAssembly. Git over SSH on port 2222 does not.

nordisk/znippy-zoomies

zstd-sys-rs/zstd/programs/zstd.1.md

zstd(1) -- zstd, zstdmt, unzstd, zstdcat - Compress or decompress .zst files

SYNOPSIS

zstd [] [-|] [-o ]

zstdmt is equivalent to zstd -T0

unzstd is equivalent to zstd -d

zstdcat is equivalent to zstd -dcf

DESCRIPTION

zstd is a fast lossless compression algorithm and data compression tool, with command line syntax similar to gzip(1) and xz(1). It is based on the LZ77 family, with further FSE & huff0 entropy stages. zstd offers highly configurable compression speed, from fast modes at > 200 MB/s per core, to strong modes with excellent compression ratios. It also features a very fast decoder, with speeds > 500 MB/s per core, which remains roughly stable at all compression settings.

zstd command line syntax is generally similar to gzip, but features the following few differences:

zstd processes each file according to the selected operation mode. If no files are given or file is -, zstd reads from standard input and writes the processed data to standard output. zstd will refuse to write compressed data to standard output if it is a terminal: it will display an error message and skip the file. Similarly, zstd will refuse to read compressed data from standard input if it is a terminal.

Unless --stdout or -o is specified, files are written to a new file whose name is derived from the source file name:

Concatenation with .zst Files

It is possible to concatenate multiple .zst files. zstd will decompress such agglomerated file as if it was a single .zst file.

OPTIONS

Integer Suffixes and Special Values

In most places where an integer argument is expected, an optional suffix is supported to easily indicate large integers. There must be no space between the integer and the suffix.

Operation Mode

If multiple operation mode options are given, the last one takes effect.

Operation Modifiers

Note 1: this mode is the only available one when multithread support is disabled.

Note 2: this mode is different from -T1, which spawns 1 compression thread in parallel with I/O. Final compressed result is also slightly different from -T1.

Note: at the time of this writing, --adapt can remain stuck at low speed when combined with multiple worker threads (>=2).

Note: If windowLog is set to larger than 27, --long=windowLog or --memory=windowSize needs to be passed to the decompressor.

Note: cannot use both this and -D together.

Note: --long mode will be automatically activated if chainLog < fileLog (fileLog being the windowLog required to cover the whole file). You can also manually force it.

Note: up to level 15, you can use --patch-from in --single-thread mode to improve compression ratio marginally at the cost of speed. Using '--single-thread' above level 15 will lead to lower compression ratios.

Note: for level 19, you can get increased compression ratio at the cost of speed by specifying --zstd=targetLength= to be something large (i.e. 4096), and by setting a large --zstd=chainLog=.

This is also used during compression when using with --patch-from=. In this case, this parameter overrides that maximum size allowed for a dictionary. (128 MiB).

Additionally, this can be used to limit memory for dictionary training. This parameter overrides the default limit of 2 GiB. zstd will load training samples up to the memory limit and ignore the rest.

If input directory contains "..", the files in this directory will be ignored. If input directory is an absolute directory (i.e. "/var/tmp/abc"), it will be stored into the "output-dir/var/tmp/abc". If there are multiple input files or directories, name collision resolution will follow the same rules as --output-dir-flat.

gzip Operation Modifiers

When invoked via a gzip symlink, zstd will support further options that intend to mimic the gzip behavior:

Environment Variables

Employing environment variables to set parameters has security implications. Therefore, this avenue is intentionally limited. Only ZSTD_CLEVEL and ZSTD_NBTHREADS are currently supported. They set the default compression level and number of threads to use during compression, respectively.

ZSTD_CLEVEL can be used to set the level between 1 and 19 (the "normal" range). If the value of ZSTD_CLEVEL is not a valid integer, it will be ignored with a warning message. ZSTD_CLEVEL just replaces the default compression level (3).

ZSTD_NBTHREADS can be used to set the number of threads zstd will attempt to use during compression. If the value of ZSTD_NBTHREADS is not a valid unsigned integer, it will be ignored with a warning message. ZSTD_NBTHREADS has a default value of max(1, min(4, nbCores/4)), and is capped at ZSTDMT_NBWORKERS_MAX==200. zstd must be compiled with multithread support for this variable to have any effect.

They can both be overridden by corresponding command line arguments: -# for compression level and -T# for number of compression threads.

ADVANCED COMPRESSION OPTIONS

zstd provides 22 predefined regular compression levels plus the fast levels. A compression level is translated internally into multiple advanced parameters that control the behavior of the compressor (one can observe the result of this translation with --show-default-cparams). These advanced parameters can be overridden using advanced compression options.

--zstd[=options]:

The options are provided as a comma-separated list. You may specify only the options you want to change and the rest will be taken from the selected or default compression level. The list of available options:

There are 9 strategies numbered from 1 to 9, from fastest to strongest: 1=ZSTD_fast, 2=ZSTD_dfast, 3=ZSTD_greedy, 4=ZSTD_lazy, 5=ZSTD_lazy2, 6=ZSTD_btlazy2, 7=ZSTD_btopt, 8=ZSTD_btultra, 9=ZSTD_btultra2.

The higher number of increases the chance to find a match which usually improves compression ratio. It also increases memory requirements for the compressor and decompressor. The minimum wlog is 10 (1 KiB) and the maximum is 30 (1 GiB) on 32-bit platforms and 31 (2 GiB) on 64-bit platforms.

Note: If windowLog is set to larger than 27, --long=windowLog or --memory=windowSize needs to be passed to the decompressor.

Bigger hash tables cause fewer collisions which usually makes compression faster, but requires more memory during compression.

The minimum hlog is 6 (64 entries / 256 B) and the maximum is 30 (1B entries / 4 GiB).

Higher numbers of bits increases the chance to find a match which usually improves compression ratio. It also slows down compression speed and increases memory requirements for compression. This option is ignored for the ZSTD_fast strategy, which only has the primary hash table.

The minimum clog is 6 (64 entries / 256 B) and the maximum is 29 (512M entries / 2 GiB) on 32-bit platforms and 30 (1B entries / 4 GiB) on 64-bit platforms.

More searches increases the chance to find a match which usually increases compression ratio but decreases compression speed.

The minimum slog is 1 and the maximum is 'windowLog' - 1.

Larger search lengths usually decrease compression ratio but improve decompression speed.

The minimum mml is 3 and the maximum is 7.

For ZSTD_btopt, ZSTD_btultra and ZSTD_btultra2, it specifies the minimum match length that causes match finder to stop searching. A larger targetLength usually improves compression ratio but decreases compression speed.

For ZSTD_fast, it triggers ultra-fast mode when > 0. The value represents the amount of data skipped between match sampling. Impact is reversed: a larger targetLength increases compression speed but decreases compression ratio.

For all other strategies, this field has no impact.

The minimum tlen is 0 and the maximum is 128 KiB.

The minimum ovlog is 0, and the maximum is 9. 1 means "no overlap", hence completely independent jobs. 9 means "full overlap", meaning up to windowSize is reloaded from previous job. Reducing ovlog by 1 reduces the reloaded amount by a factor 2. For example, 8 means "windowSize/2", and 6 means "windowSize/8". Value 0 is special and means "default": ovlog is automatically determined by zstd. In which case, ovlog will range from 6 to 9, depending on selected strat.

This option is ignored unless long distance matching is enabled.

Larger values will improve compression speed. Deviating far from the default value will likely result in a decrease in compression ratio.

The default value varies between 4 and 7, depending on strategy.

This option is ignored unless long distance matching is enabled.

Bigger hash tables usually improve compression ratio at the expense of more memory during compression and a decrease in compression speed.

The minimum lhlog is 6 and the maximum is 30 (default: windowLog - ldmHashRateLog).

This option is ignored unless long distance matching is enabled.

Larger/very small values usually decrease compression ratio.

The minimum lmml is 4 and the maximum is 4096 (default: 32 to 64, depending on strategy).

This option is ignored unless long distance matching is enabled.

Larger bucket sizes improve collision resolution but decrease compression speed.

The minimum lblog is 1 and the maximum is 8 (default: 4 to 8, depending on strategy).

Example

The following parameters sets advanced compression options to something similar to predefined level 19 for files bigger than 256 KB:

--zstd=wlog=23,clog=23,hlog=22,slog=6,mml=3,tlen=48,strat=6

-B#:

Specify the size of each compression job. This parameter is only available when multi-threading is enabled. Each compression job is run in parallel, so this value indirectly impacts the nb of active threads. Default job size varies depending on compression level (generally 4 * windowSize). -B# makes it possible to manually select a custom size. Note that job size must respect a minimum value which is enforced transparently. This minimum is either 512 KB, or overlapSize, whichever is largest. Different job sizes will lead to non-identical compressed frames.

DICTIONARY BUILDER

zstd offers dictionary compression, which greatly improves efficiency on small files and messages. It's possible to train zstd with a set of samples, the result of which is saved into a file called a dictionary. Then, during compression and decompression, reference the same dictionary, using command -D dictionaryFileName. Compression of small files similar to the sample set will be greatly improved.

Since dictionary compression is mostly effective for small files, the expectation is that the training set will only contain small files. In the case where some samples happen to be large, only the first 128 KiB of these samples will be used for training.

--train supports multithreading if zstd is compiled with threading support (default). Additional advanced parameters can be specified with --train-fastcover. The legacy dictionary builder can be accessed with --train-legacy. The slower cover dictionary builder can be accessed with --train-cover. Default --train is equivalent to --train-fastcover=d=8,steps=4.

In situations where the training set is larger than maximum memory, the CLI will randomly select samples among the available ones, up to the maximum allowed memory budget. This is meant to improve dictionary relevance by mitigating the potential impact of clustering, such as selecting only files from the beginning of a list sorted by modification date, or sorted by alphabetical order. The randomization process is deterministic, so training of the same list of files with the same parameters will lead to the creation of the same dictionary.

Note that RFC8878 reserves IDs less than 32768 and greater than or equal to 2^31, so they should not be used in public.

Selects segments of size k with highest score to put in the dictionary. The score of a segment is computed by the sum of the frequencies of all the subsegments of size d. Generally d should be in the range [6, 8], occasionally up to 16, but the algorithm will run faster with d <= 8. Good values for k vary widely based on the input data, but a safe range is [2 * d, 2000]. If split is 100, all input samples are used for both training and testing to find optimal d and k to build dictionary. Supports multithreading if zstd is compiled with threading support. Having shrink enabled takes a truncated dictionary of minimum size and doubles in size until compression ratio of the truncated dictionary is at most shrinkDictMaxRegression% worse than the compression ratio of the largest dictionary.

Examples:

zstd --train-cover FILEs

zstd --train-cover=k=50,d=8 FILEs

zstd --train-cover=d=8,steps=500 FILEs

zstd --train-cover=k=50 FILEs

zstd --train-cover=k=50,split=60 FILEs

zstd --train-cover=shrink FILEs

zstd --train-cover=shrink=2 FILEs

f is log of size of array that keeps track of frequency of subsegments of size d. The subsegment is hashed to an index in the range [0,2^f - 1]. It is possible that 2 different subsegments are hashed to the same index, and they are considered as the same subsegment when computing frequency. Using a higher f reduces collision but takes longer.

Examples:

zstd --train-fastcover FILEs

zstd --train-fastcover=d=8,f=15,accel=2 FILEs

Examples:

zstd --train-legacy FILEs

zstd --train-legacy=selectivity=8 FILEs

BENCHMARK

The zstd CLI provides a benchmarking mode that can be used to easily find suitable compression parameters, or alternatively to benchmark a computer's performance. zstd -b [FILE(s)] will benchmark zstd for both compression and decompression using default compression level. Note that results are very dependent on the content being compressed.

It's possible to pass multiple files to the benchmark, and even a directory with -r DIRECTORY. When no FILE is provided, the benchmark will use a procedurally generated lorem ipsum text.

Benchmarking will employ max(1, min(4, nbCores/4)) worker threads by default in order to match the behavior of the normal CLI I/O.

Beyond compression levels, benchmarking is also compatible with other parameters, such as number of threads (-T#), advanced compression parameters (--zstd=###), dictionary compression (-D dictionary), or even disabling checksum verification for example.

Output Format: CompressionLevel#Filename: InputSize -> OutputSize (CompressionRatio), CompressionSpeed, DecompressionSpeed

Methodology: For speed measurement, the entire input is compressed/decompressed in-memory to measure speed. A run lasts at least 1 sec, so when files are small, they are compressed/decompressed several times per run, in order to improve measurement accuracy.

SEE ALSO

zstdgrep(1), zstdless(1), gzip(1), xz(1)

The format is specified in Y. Collet, "Zstandard Compression and the 'application/zstd' Media Type", https://www.ietf.org/rfc/rfc8878.txt, Internet RFC 8878 (February 2021).

BUGS

Report bugs at: https://github.com/facebook/zstd/issues

AUTHOR

Yann Collet