neulab/tldr huggingface dataset:
[[     Backs up to the previous section boundary.  A section begins at each macro in the sections option, normally a `.NH' or `.SH' and also at lines which which start with a formfeed ^L.  Lines beginning with { also stop [[; this makes it useful for looking backwards, a function at a time, in C programs.  If the option lisp is set, stops at each ( at the beginning of a line, and is thus useful for moving backwards at the top level LISP objects. (4.2, 6.1, 6.6, 7.2).
\      Unused.
]]     Forward to a section boundary, see [[ for a definition (4.2, 6.1, 6.6, 7.2).
^      Moves to the first non-white position on the current line (4.4).
_      Unused.
`      When followed by a ` returns to the previous context.  The previous context is set whenever the current line is moved in a non-relative way.  When followed by a letter a-z, returns to the position which was marked with this letter with a m command.  When used with an operator such as d, the operation takes place from the exact marked place to the current position within the line; if using ´, the operation takes place over complete lines (2.2, 5.3).
a      Appends arbitrary text after the current cursor position; the insert can continue onto multiple lines by using RETURN within the insert.  A count causes the inserted text to be replicated, but only if the inserted text is all on one line.  The insertion terminates with an ESC (3.1, 7.2).
b      Backs up to the beginning of a word in the current line.  A word is a sequence of alphanumerics, or a sequence of special characters.  A count repeats the effect (2.4).
c      An operator which changes the following object, replacing it with the following input text up to an ESC.  If more than part of a single line is affected, the text which is changed away is saved in the numeric named buffers.  If only part of the current line is affected, then the last character to be changed away is marked with a $.  A count causes that many objects to be affected, thus both 3c) and c3) change the following three sentences (7.4).
d      An operator which deletes the following object.  If more than part of a line is affected, the text is saved in the numeric buffers. A count causes that many objects to be affected; thus 3dw is the same as d3w (3.3, 3.4, 4.1, 7.4).
e      Advances to the end of the next word, defined as for b and w.  A count repeats the effect (2.4, 3.1).
f      Finds the first instance of the next character following the cursor on the current line.  A count repeats the find (4.1).
g      Unused.
Arrow keys h, j, k, l, and H.
h      Left arrow .  Moves the cursor one character to the left.  Like the other arrow keys, either h, the left arrow key, or one of the synonyms (^H) has the same effect.  A count repeats the effect (3.1, 7.5).
i      Inserts text before the cursor, otherwise like a (7.2).
j      Down arrow .  Moves the cursor one line down in the same column. If the position does not exist, vi comes as close as possible to the same column.  Synonyms include ^J (linefeed) and ^N .
k      Up arrow .  Moves the cursor one line up.  ^P is a synonym.
l      Right arrow .  Moves the cursor one character to the right.  SPACE is a synonym.
m      Marks the current position of the cursor in the mark register which is specified by the next character a-z.  The user can return to this position or use it with an operator using ` or ´ (5.3).
n      Repeats the last / or ? scanning commands (2.2).
o      Opens new lines below the current line; otherwise like O (3.1).
p      Puts text after/below the cursor; otherwise like P (6.3).
q      Unused.
r      Replaces the single character at the cursor with a single character typed.  The new character may be a RETURN; this is the easiest way to split lines.  A count replaces each of the following count characters with the single character given; see R above which is the more usually useful iteration of r (3.2).
s      Changes the single character under the cursor to the text which follows up to an ESC; given a count, that many characters from the current line are changed.  The last character to be changed is marked with $ as in c (3.2).
t      Advances the cursor upto the character before the next character typed.  Most useful with operators such as d and c to delete the characters up to a following character.  One can use . to delete more if this doesn't delete enough the first time (4.1).
u      Undoes the last change made to the current buffer.  If repeated, will alternate between these two states, thus is its own inverse. When used after an insert which inserted text on more than one line, the lines are saved in the numeric named buffers (3.5).
v      Unused.
w      Advances to the beginning of the next word, as defined by b (2.4).
x      Deletes the single character under the cursor.  With a count deletes deletes that many characters forward from the cursor position, but only on the current line (6.5).
y      An operator, yanks the following object into the unnamed temporary buffer.  If preceded by a named buffer specification, "x, the text is placed in that buffer also.  Text can be recovered by a later p or P (7.4).
z      Redraws the screen with the current line placed as specified by the following character: RETURN specifies the top of the screen, . the center of the screen, and - at the bottom of the screen.  A count may be given after the z and before the following character to specify the new screen size for the redraw.  A count before the z gives the number of the line to place in the center of the screen instead of the default current line. (5.4)
{      Retreats to the beginning of the beginning of the preceding paragraph.  A paragraph begins at each macro in the paragraphs option, normally `.IP', `.LP', `.PP', `.QP' and `.bp'.  A paragraph also begins after a completely empty line, and at each section boundary (see [[ above) (4.2, 6.8, 7.6).
|      Places the cursor on the character in the column specified by the count (7.1, 7.2).
}      Advances to the beginning of the next paragraph.  See { for the definition of paragraph (4.2, 6.8, 7.6).
~      Switches the case of the given count of characters starting from the current cursor position to the end of the current line.  Non- alphabetic characters remain unchanged.
^? (DEL) Interrupts the editor, returning it to command accepting state (1.6, 7.5).
The following environment variables affect the behaviour of vi:
COLUMNS Overrides the system-supplied number of terminal columns.
EXINIT Contains commands to execute at editor startup.  If this variable is present, the .exrc file in the user's home directory is ignored.
HOME   Used to locate the editor startup file.
LANG, LC_ALL See locale(7).
LC_CTYPE Determines the mapping of bytes to characters, types of characters, case conversion and composition of character classes in regular expressions.
LC_MESSAGES Sets the language used for diagnostic and informal messages.
LINES  Overrides the system-supplied number of terminal lines.
NLSPATH See catopen(3).
SHELL  The program file used to execute external commands.
TERM   Determines the terminal type.
/usr/lib/ex/expreserve preserve command
/usr/lib/ex/exrecover recover command
/etc/termcap describes capabilities of terminals
$HOME/.exrc editor startup file
/var/tmp/Exnnnnnnnnnn editor temporary
/var/tmp/Rxnnnnnnnnnn named buffer temporary
/var/lib/ex preservation directory
ex(1), edit(1), “Vi Quick Reference” card, “An Introduction to Display Editing with Vi”.
William Joy.
Mark Horton added macros to visual mode and was maintaining version 3.
This version incorporates changes by Gunnar Ritter.
Software tabs using ^T work only immediately after the autoindent.
Left and right shifts on intelligent terminals don't make use of insert and delete character operations in the terminal.
The wrapmargin option can be fooled since it looks at output columns when blanks are typed.  If a long word passes through the margin and onto the next line without a break, then the line won't be broken.
Insert/delete within a line can be slow if tabs are present on intelligent terminals, since the terminals need help in doing this correctly.
The source command does not work when executed as :source; there is no way to use the :append, :change, and :insert commands, since it is not possible to give more than one line of input to a : escape.  To use these on a :global one must Q to ex command mode, execute them, and then reenter the screen editor with vi or open.
bzip2(1)                     General Commands Manual                    bzip2(1)
bzip2, bunzip2 - a block-sorting file compressor, v1.0.8 bzcat - decompresses files to stdout bzip2recover - recovers data from damaged bzip2 files
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ...  ] bunzip2 [ -fkvsVL ] [ filenames ...  ] bzcat [ -s ] [ filenames ...  ] bzip2recover filename
bzip2 compresses files using the Burrows-Wheeler block sorting text compression algorithm, and Huffman coding.  Compression is generally considerably better than that achieved by more conventional LZ77/LZ78-based compressors, and approaches the performance of the PPM family of statistical compressors.
The command-line options are deliberately very similar to those of GNU gzip, but they are not identical.
bzip2 expects a list of file names to accompany the command-line flags. Each file is replaced by a compressed version of itself, with the name "original_name.bz2".  Each compressed file has the same modification date, permissions, and, when possible, ownership as the corresponding original, so that these properties can be correctly restored at decompression time.  File name handling is naive in the sense that there is no mechanism for preserving original file names, permissions, ownerships or dates in filesystems which lack these concepts, or have serious file name length restrictions, such as MS-DOS.
bzip2 and bunzip2 will by default not overwrite existing files.  If you want this to happen, specify the -f flag.
If no file names are specified, bzip2 compresses from standard input to standard output.  In this case, bzip2 will decline to write compressed output to a terminal, as this would be entirely incomprehensible and therefore pointless.
bunzip2 (or bzip2 -d) decompresses all specified files.  Files which were not created by bzip2 will be detected and ignored, and a warning issued. bzip2 attempts to guess the filename for the decompressed file from that of the compressed file as follows:
filename.bz2    becomes   filename filename.bz     becomes   filename filename.tbz2   becomes   filename.tar filename.tbz    becomes   filename.tar anyothername    becomes   anyothername.out
If the file does not end in one of the recognised endings, .bz2, .bz, .tbz2 or .tbz, bzip2 complains that it cannot guess the name of the original file, and uses the original name with .out appended.
As with compression, supplying no filenames causes decompression from standard input to standard output.
bunzip2 will correctly decompress a file which is the concatenation of two or more compressed files.  The result is the concatenation of the corresponding uncompressed files.  Integrity testing (-t) of concatenated compressed files is also supported.
You can also compress or decompress files to the standard output by giving the -c flag.  Multiple files may be compressed and decompressed like this.  The resulting outputs are fed sequentially to stdout. Compression of multiple files in this manner generates a stream containing multiple compressed file representations.  Such a stream can be decompressed correctly only by bzip2 version 0.9.0 or later.  Earlier versions of bzip2 will stop after decompressing the first file in the stream.
bzcat (or bzip2 -dc) decompresses all specified files to the standard output.
bzip2 will read arguments from the environment variables BZIP2 and BZIP, in that order, and will process them before any arguments read from the command line.  This gives a convenient way to supply default arguments.
Compression is always performed, even if the compressed file is slightly larger than the original.  Files of less than about one hundred bytes tend to get larger, since the compression mechanism has a constant overhead in the region of 50 bytes.  Random data (including the output of most file compressors) is coded at about 8.05 bits per byte, giving an expansion of around 0.5%.
As a self-check for your protection, bzip2 uses 32-bit CRCs to make sure that the decompressed version of a file is identical to the original. This guards against corruption of the compressed data, and against undetected bugs in bzip2 (hopefully very unlikely).  The chances of data corruption going undetected is microscopic, about one chance in four billion for each file processed.  Be aware, though, that the check occurs upon decompression, so it can only tell you that something is wrong.  It can't help you recover the original uncompressed data.  You can use bzip2recover to try to recover data from damaged files.
Return values: 0 for a normal exit, 1 for environmental problems (file not found, invalid flags, I/O errors, &c), 2 to indicate a corrupt compressed file, 3 for an internal consistency error (eg, bug) which caused bzip2 to panic.
-c --stdout Compress or decompress to standard output.
-d --decompress Force decompression.  bzip2, bunzip2 and bzcat are really the same program, and the decision about what actions to take is done on the basis of which name is used.  This flag overrides that mechanism, and forces bzip2 to decompress.
-z --compress The complement to -d: forces compression, regardless of the invocation name.
-t --test Check integrity of the specified file(s), but don't decompress them.  This really performs a trial decompression and throws away the result.
-f --force Force overwrite of output files.  Normally, bzip2 will not overwrite existing output files.  Also forces bzip2 to break hard links to files, which it otherwise wouldn't do.
bzip2 normally declines to decompress files which don't have the correct magic header bytes.  If forced (-f), however, it will pass such files through unmodified.  This is how GNU gzip behaves.
-s --small Reduce memory usage, for compression, decompression and testing. Files are decompressed and tested using a modified algorithm which only requires 2.5 bytes per block byte.  This means any file can be decompressed in 2300k of memory, albeit at about half the normal speed.
During compression, -s selects a block size of 200k, which limits memory use to around the same figure, at the expense of your compression ratio.  In short, if your machine is low on memory (8 megabytes or less), use -s for everything.  See MEMORY MANAGEMENT below.
-q --quiet Suppress non-essential warning messages.  Messages pertaining to I/O errors and other critical events will not be suppressed.
-v --verbose Verbose mode -- show the compression ratio for each file processed.  Further -v's increase the verbosity level, spewing out lots of information which is primarily of interest for diagnostic purposes.
-L --license -V --version Display the software version, license terms and conditions.
-1 (or --fast) to -9 (or --best) Set the block size to 100 k, 200 k ..  900 k when compressing. Has no effect when decompressing.  See MEMORY MANAGEMENT below. The --fast and --best aliases are primarily for GNU gzip compatibility.  In particular, --fast doesn't make things significantly faster.  And --best merely selects the default behaviour.
--     Treats all subsequent arguments as file names, even if they start with a dash.  This is so you can handle files with names beginning with a dash, for example: bzip2 -- -myfilename.
--repetitive-fast --repetitive-best These flags are redundant in versions 0.9.5 and above.  They provided some coarse control over the behaviour of the sorting algorithm in earlier versions, which was sometimes useful.  0.9.5 and above have an improved algorithm which renders these flags irrelevant.
bzip2 compresses large files in blocks.  The block size affects both the compression ratio achieved, and the amount of memory needed for compression and decompression.  The flags -1 through -9 specify the block size to be 100,000 bytes through 900,000 bytes (the default) respectively.  At decompression time, the block size used for compression is read from the header of the compressed file, and bunzip2 then allocates itself just enough memory to decompress the file.  Since block sizes are stored in compressed files, it follows that the flags -1 to -9 are irrelevant to and so ignored during decompression.
Compression and decompression requirements, in bytes, can be estimated as:
Compression:   400k + ( 8 x block size )
Decompression: 100k + ( 4 x block size ), or 100k + ( 2.5 x block size )
Larger block sizes give rapidly diminishing marginal returns.  Most of the compression comes from the first two or three hundred k of block size, a fact worth bearing in mind when using bzip2 on small machines. It is also important to appreciate that the decompression memory requirement is set at compression time by the choice of block size.
For files compressed with the default 900k block size, bunzip2 will require about 3700 kbytes to decompress.  To support decompression of any file on a 4 megabyte machine, bunzip2 has an option to decompress using approximately half this amount of memory, about 2300 kbytes. Decompression speed is also halved, so you should use this option only where necessary.  The relevant flag is -s.
In general, try and use the largest block size memory constraints allow, since that maximises the compression achieved.  Compression and decompression speed are virtually unaffected by block size.
Another significant point applies to files which fit in a single block -- that means most files you'd encounter using a large block size.  The amount of real memory touched is proportional to the size of the file, since the file is smaller than a block.  For example, compressing a file 20,000 bytes long with the flag -9 will cause the compressor to allocate around 7600k of memory, but only touch 400k + 20000 * 8 = 560 kbytes of it.  Similarly, the decompressor will allocate 3700k but only touch 100k + 20000 * 4 = 180 kbytes.
Here is a table which summarises the maximum memory usage for different block sizes.  Also recorded is the total compressed size for 14 files of the Calgary Text Compression Corpus totalling 3,141,622 bytes.  This column gives some feel for how compression varies with block size.  These figures tend to understate the advantage of larger block sizes for larger files, since the Corpus is dominated by smaller files.
Compress   Decompress   Decompress   Corpus Flag     usage      usage       -s usage     Size
-1      1200k       500k         350k      914704 -2      2000k       900k         600k      877703 -3      2800k      1300k         850k      860338 -4      3600k      1700k        1100k      846899 -5      4400k      2100k        1350k      845160 -6      5200k      2500k        1600k      838626 -7      6100k      2900k        1850k      834096 -8      6800k      3300k        2100k      828642 -9      7600k      3700k        2350k      828642
bzip2 compresses files in blocks, usually 900kbytes long.  Each block is handled independently.  If a media or transmission error causes a multi- block .bz2 file to become damaged, it may be possible to recover data from the undamaged blocks in the file.
The compressed representation of each block is delimited by a 48-bit pattern, which makes it possible to find the block boundaries with reasonable certainty.  Each block also carries its own 32-bit CRC, so damaged blocks can be distinguished from undamaged ones.
bzip2recover is a simple program whose purpose is to search for blocks in .bz2 files, and write each block out into its own .bz2 file.  You can then use bzip2 -t to test the integrity of the resulting files, and decompress those which are undamaged.
bzip2recover takes a single argument, the name of the damaged file, and writes a number of files "rec00001file.bz2", "rec00002file.bz2", etc, containing the  extracted  blocks.  The  output  filenames  are  designed so  that the use of wildcards in subsequent processing -- for example, "bzip2 -dc  rec*file.bz2 > recovered_data" -- processes the files in the correct order.
bzip2recover should be of most use dealing with large .bz2 files,  as these will contain many blocks.  It is clearly futile to use it on damaged single-block  files,  since  a damaged  block  cannot  be recovered.  If you wish to minimise any potential data loss through media or  transmission errors, you might consider compressing with a smaller block size.
The sorting phase of compression gathers together similar strings in the file.  Because of this, files containing very long runs of repeated symbols, like "aabaabaabaab ..."  (repeated several hundred times) may compress more slowly than normal.  Versions 0.9.5 and above fare much better than previous versions in this respect.  The ratio between worst- case and average-case compression time is in the region of 10:1.  For previous versions, this figure was more like 100:1.  You can use the -vvvv option to monitor progress in great detail, if you want.
Decompression speed is unaffected by these phenomena.
bzip2 usually allocates several megabytes of memory to operate in, and then charges all over it in a fairly random fashion.  This means that performance, both for compressing and decompressing, is largely determined by the speed at which your machine can service cache misses. Because of this, small changes to the code to reduce the miss rate have been observed to give disproportionately large performance improvements. I imagine bzip2 will perform best on machines with very large caches.
I/O error messages are not as helpful as they could be.  bzip2 tries hard to detect I/O errors and exit cleanly, but the details of what the problem is sometimes seem rather misleading.
This manual page pertains to version 1.0.8 of bzip2.  Compressed data created by this version is entirely forwards and backwards compatible with the previous public releases, versions 0.1pl2, 0.9.0, 0.9.5, 1.0.0, 1.0.1, 1.0.2 and above, but with the following exception: 0.9.0 and above can correctly decompress multiple concatenated compressed files.  0.1pl2 cannot do this; it will stop after decompressing just the first file in the stream.
bzip2recover versions prior to 1.0.2 used 32-bit integers to represent bit positions in compressed files, so they could not handle compressed files more than 512 megabytes long.  Versions 1.0.2 and above use 64-bit ints on some platforms which support them (GNU supported targets, and Windows).  To establish whether or not bzip2recover was built with such a limitation, run it without arguments.  In any event you can build yourself an unlimited version if you can recompile it with MaybeUInt64 set to be an unsigned 64-bit integer.
Julian Seward, jseward@acm.org.
https://sourceware.org/bzip2/
The ideas embodied in bzip2 are due to (at least) the following people: Michael Burrows and David Wheeler (for the block sorting transformation), David Wheeler (again, for the Huffman coder), Peter Fenwick (for the structured coding model in the original bzip, and many refinements), and Alistair Moffat, Radford Neal and Ian Witten (for the arithmetic coder in the original bzip).  I am much indebted for their help, support and advice.  See the manual in the source distribution for pointers to sources of documentation.  Christian von Roques encouraged me to look for faster sorting algorithms, so as to speed up compression.  Bela Lubkin encouraged me to improve the worst-case compression performance.  Donna Robinson XMLised the documentation.  The bz* scripts are derived from those of GNU gzip.  Many people sent patches, helped with portability problems, lent machines, gave advice and were generally helpful.
QEMU-IMG(1)                           QEMU                           QEMU-IMG(1)
qemu-img - QEMU disk image utility
qemu-img [standard options] command [command options]
qemu-img allows you to create, convert and modify images offline. It can handle all image formats supported by QEMU.
Warning: Never use qemu-img to modify images in use by a running virtual machine or any other process; this may destroy the image. Also, be aware that querying an image that is being modified by another process may encounter inconsistent state.
Standard options:
-h, --help Display this help and exit
-T, --trace [[enable=]PATTERN][,events=FILE][,file=FILE] Specify tracing options.
The following commands are supported:
amend [--object OBJECTDEF] [--image-opts] [-p] [-q] [-f FMT] [-t CACHE] [--force] -o OPTIONS FILENAME
bench [-c COUNT] [-d DEPTH] [-f FMT] [--flush-interval=FLUSH_INTERVAL] [-i AIO] [-n] [--no-drain] [-o OFFSET] [--pattern=PATTERN] [-q] [-s BUFFER_SIZE] [-S STEP_SIZE] [-t CACHE] [-w] [-U] FILENAME
bitmap (--merge SOURCE | --add | --remove | --clear | --enable | --disable)... [-b SOURCE_FILE [-F SOURCE_FMT]] [-g GRANULARITY] [--object OBJECTDEF] [--image-opts | -f FMT] FILENAME BITMAP
check [--object OBJECTDEF] [--image-opts] [-q] [-f FMT] [--output=OFMT] [-r [leaks | all]] [-T SRC_CACHE] [-U] FILENAME
commit [--object OBJECTDEF] [--image-opts] [-q] [-f FMT] [-t CACHE] [-b BASE] [-r RATE_LIMIT] [-d] [-p] FILENAME
compare [--object OBJECTDEF] [--image-opts] [-f FMT] [-F FMT] [-T SRC_CACHE] [-p] [-q] [-s] [-U] FILENAME1 FILENAME2
convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [--target-is-zero] [--bitmaps] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-r RATE_LIMIT] [-m NUM_COROUTINES] [-W] [--salvage] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME
create [--object OBJECTDEF] [-q] [-f FMT] [-b BACKING_FILE] [-F BACKING_FMT] [-u] [-o OPTIONS] FILENAME [SIZE]
dd [--image-opts] [-U] [-f FMT] [-O OUTPUT_FMT] [bs=BLOCK_SIZE] [count=BLOCKS] [skip=BLOCKS] if=INPUT of=OUTPUT
info [--object OBJECTDEF] [--image-opts] [-f FMT] [--output=OFMT] [--backing-chain] [-U] FILENAME
map [--object OBJECTDEF] [--image-opts] [-f FMT] [--start-offset=OFFSET] [--max-length=LEN] [--output=OFMT] [-U] FILENAME
measure [--output=OFMT] [-O OUTPUT_FMT] [-o OPTIONS] [--size N | [--object OBJECTDEF] [--image-opts] [-f FMT] [-l SNAPSHOT_PARAM] FILENAME]
snapshot [--object OBJECTDEF] [--image-opts] [-U] [-q] [-l | -a SNAPSHOT | -c SNAPSHOT | -d SNAPSHOT] FILENAME
rebase [--object OBJECTDEF] [--image-opts] [-U] [-q] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-p] [-u] -b BACKING_FILE [-F BACKING_FMT] FILENAME
resize [--object OBJECTDEF] [--image-opts] [-f FMT] [--preallocation=PREALLOC] [-q] [--shrink] FILENAME [+ | -]SIZE
Command parameters:
FILENAME is a disk image filename.
FMT is the disk image format. It is guessed automatically in most cases. See below for a description of the supported disk formats.
SIZE is the disk image size in bytes. Optional suffixes k or K (kilobyte, 1024) M (megabyte, 1024k) and G (gigabyte, 1024M) and T (terabyte, 1024G) are supported.  b is ignored.
OUTPUT_FILENAME is the destination disk image filename.
OUTPUT_FMT is the destination format.
OPTIONS is a comma separated list of format specific options in a name=value format. Use -o ? for an overview of the options supported by the used format or see the format descriptions below for details.
SNAPSHOT_PARAM is param used for internal snapshot, format is 'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]'.
--object OBJECTDEF is a QEMU user creatable object definition. See the qemu(1) manual page for a description of the object properties. The most common object type is a secret, which is used to supply passwords and/or encryption keys.
--image-opts Indicates that the source FILENAME parameter is to be interpreted as a full option string, not a plain filename. This parameter is mutually exclusive with the -f parameter.
--target-image-opts Indicates that the OUTPUT_FILENAME parameter(s) are to be interpreted as a full option string, not a plain filename. This parameter is mutually exclusive with the -O parameters. It is currently required to also use the -n parameter to skip image creation. This restriction may be relaxed in a future release.
--force-share (-U) If specified, qemu-img will open the image in shared mode, allowing other QEMU processes to open it in write mode. For example, this can be used to get the image information (with 'info' subcommand) when the image is used by a running guest. Note that this could produce inconsistent results because of concurrent metadata changes, etc. This option is only allowed when opening images in read-only mode.
--backing-chain Will enumerate information about backing files in a disk image chain. Refer below for further description.
-c     Indicates that target image must be compressed (qcow format only).
-h     With or without a command, shows help and lists the supported formats.
-p     Display progress bar (compare, convert and rebase commands only). If the -p option is not used for a command that supports it, the progress is reported when the process receives a SIGUSR1 or SIGINFO signal.
-q     Quiet mode - do not print any output (except errors). There's no progress bar in case both -q and -p options are used.
-S SIZE Indicates the consecutive number of bytes that must contain only zeros for qemu-img to create a sparse image during conversion. This value is rounded down to the nearest 512 bytes. You may use the common size suffixes like k for kilobytes.
-t CACHE Specifies the cache mode that should be used with the (destination) file. See the documentation of the emulator's -drive cache=... option for allowed values.
-T SRC_CACHE Specifies the cache mode that should be used with the source file(s). See the documentation of the emulator's -drive cache=... option for allowed values.
Parameters to compare subcommand:
-f     First image format
-F     Second image format
-s     Strict mode - fail on different image size or sector allocation
Parameters to convert subcommand:
--bitmaps Additionally copy all persistent bitmaps from the top layer of the source
-n     Skip the creation of the target volume
-m     Number of parallel coroutines for the convert process
-W     Allow out-of-order writes to the destination. This option improves performance, but is only recommended for preallocated devices like host devices or other raw block devices.
-C     Try to use copy offloading to move data from source image to target. This may improve performance if the data is remote, such as with NFS or iSCSI backends, but will not automatically sparsify zero sectors, and may result in a fully allocated target image depending on the host support for getting allocation information.
-r     Rate limit for the convert process
--salvage Try to ignore I/O errors when reading.  Unless in quiet mode (-q), errors will still be printed.  Areas that cannot be read from the source will be treated as containing only zeroes.
--target-is-zero Assume that reading the destination image will always return zeros. This parameter is mutually exclusive with a destination image that has a backing file. It is required to also use the -n parameter to skip image creation.
Parameters to dd subcommand:
bs=BLOCK_SIZE Defines the block size
count=BLOCKS Sets the number of input blocks to copy
if=INPUT Sets the input file
of=OUTPUT Sets the output file
skip=BLOCKS Sets the number of input blocks to skip
Parameters to snapshot subcommand:
snapshot Is the name of the snapshot to create, apply or delete
-a     Applies a snapshot (revert disk to saved state)
-c     Creates a snapshot
-d     Deletes a snapshot
-l     Lists all snapshots in the given image
Command description:
amend [--object OBJECTDEF] [--image-opts] [-p] [-q] [-f FMT] [-t CACHE] [--force] -o OPTIONS FILENAME Amends the image format specific OPTIONS for the image file FILENAME. Not all file formats support this operation.
The set of options that can be amended are dependent on the image format, but note that amending the backing chain relationship should instead be performed with qemu-img rebase.
--force allows some unsafe operations. Currently for -f luks, it allows to erase the last encryption key, and to overwrite an active encryption key.
bench [-c COUNT] [-d DEPTH] [-f FMT] [--flush-interval=FLUSH_INTERVAL] [-i AIO] [-n] [--no-drain] [-o OFFSET] [--pattern=PATTERN] [-q] [-s BUFFER_SIZE] [-S STEP_SIZE] [-t CACHE] [-w] [-U] FILENAME Run a simple sequential I/O benchmark on the specified image. If -w is specified, a write test is performed, otherwise a read test is performed.
A total number of COUNT I/O requests is performed, each BUFFER_SIZE bytes in size, and with DEPTH requests in parallel. The first request starts at the position given by OFFSET, each following request increases the current position by STEP_SIZE. If STEP_SIZE is not given, BUFFER_SIZE is used for its value.
If FLUSH_INTERVAL is specified for a write test, the request queue is drained and a flush is issued before new writes are made whenever the number of remaining requests is a multiple of FLUSH_INTERVAL. If additionally --no-drain is specified, a flush is issued without draining the request queue first.
if -i is specified, AIO option can be used to specify different AIO backends: threads, native or io_uring.
If -n is specified, the native AIO backend is used if possible. On Linux, this option only works if -t none or -t directsync is specified as well.
For write tests, by default a buffer filled with zeros is written. This can be overridden with a pattern byte specified by PATTERN.
bitmap (--merge SOURCE | --add | --remove | --clear | --enable | --disable)... [-b SOURCE_FILE [-F SOURCE_FMT]] [-g GRANULARITY] [--object OBJECTDEF] [--image-opts | -f FMT] FILENAME BITMAP Perform one or more modifications of the persistent bitmap BITMAP in the disk image FILENAME.  The various modifications are:
--add to create BITMAP, enabled to record future edits.
--remove to remove BITMAP.
--clear to clear BITMAP.
--enable to change BITMAP to start recording future edits.
--disable to change BITMAP to stop recording future edits.
--merge to merge the contents of the SOURCE bitmap into BITMAP.
Additional options include -g which sets a non-default GRANULARITY for --add, and -b and -F which select an alternative source file for all SOURCE bitmaps used by --merge.
To see what bitmaps are present in an image, use qemu-img info.
check [--object OBJECTDEF] [--image-opts] [-q] [-f FMT] [--output=OFMT] [-r [leaks | all]] [-T SRC_CACHE] [-U] FILENAME Perform a consistency check on the disk image FILENAME. The command can output in the format OFMT which is either human or json.  The JSON output is an object of QAPI type ImageCheck.
If -r is specified, qemu-img tries to repair any inconsistencies found during the check. -r leaks repairs only cluster leaks, whereas -r all fixes all kinds of errors, with a higher risk of choosing the wrong fix or hiding corruption that has already occurred.
Only the formats qcow2, qed and vdi support consistency checks.
In case the image does not have any inconsistencies, check exits with 0.  Other exit codes indicate the kind of inconsistency found or if another error occurred. The following table summarizes all exit codes of the check subcommand:
0      Check completed, the image is (now) consistent
1      Check not completed because of internal errors
2      Check completed, image is corrupted
3      Check completed, image has leaked clusters, but is not corrupted
63     Checks are not supported by the image format
If -r is specified, exit codes representing the image state refer to the state after (the attempt at) repairing it. That is, a successful -r all will yield the exit code 0, independently of the image state before.
commit [--object OBJECTDEF] [--image-opts] [-q] [-f FMT] [-t CACHE] [-b BASE] [-r RATE_LIMIT] [-d] [-p] FILENAME Commit the changes recorded in FILENAME in its base image or backing file.  If the backing file is smaller than the snapshot, then the backing file will be resized to be the same size as the snapshot.  If the snapshot is smaller than the backing file, the backing file will not be truncated.  If you want the backing file to match the size of the smaller snapshot, you can safely truncate it yourself once the commit operation successfully completes.
The image FILENAME is emptied after the operation has succeeded. If you do not need FILENAME afterwards and intend to drop it, you may skip emptying FILENAME by specifying the -d flag.
If the backing chain of the given image file FILENAME has more than one layer, the backing file into which the changes will be committed may be specified as BASE (which has to be part of FILENAME's backing chain). If BASE is not specified, the immediate backing file of the top image (which is FILENAME) will be used. Note that after a commit operation all images between BASE and the top image will be invalid and may return garbage data when read. For this reason, -b implies -d (so that the top image stays valid).
The rate limit for the commit process is specified by -r.
compare [--object OBJECTDEF] [--image-opts] [-f FMT] [-F FMT] [-T SRC_CACHE] [-p] [-q] [-s] [-U] FILENAME1 FILENAME2 Check if two images have the same content. You can compare images with different format or settings.
The format is probed unless you specify it by -f (used for FILENAME1) and/or -F (used for FILENAME2) option.
By default, images with different size are considered identical if the larger image contains only unallocated and/or zeroed sectors in the area after the end of the other image. In addition, if any sector is not allocated in one image and contains only zero bytes in the second one, it is evaluated as equal. You can use Strict mode by specifying the -s option. When compare runs in Strict mode, it fails in case image size differs or a sector is allocated in one image and is not allocated in the second one.
By default, compare prints out a result message. This message displays information that both images are same or the position of the first different byte. In addition, result message can report different image size in case Strict mode is used.
Compare exits with 0 in case the images are equal and with 1 in case the images differ. Other exit codes mean an error occurred during execution and standard error output should contain an error message.  The following table sumarizes all exit codes of the compare subcommand:
0      Images are identical (or requested help was printed)
1      Images differ
2      Error on opening an image
3      Error on checking a sector allocation
4      Error on reading data
convert [--object OBJECTDEF] [--image-opts] [--target-image-opts] [--target-is-zero] [--bitmaps [--skip-broken-bitmaps]] [-U] [-C] [-c] [-p] [-q] [-n] [-f FMT] [-t CACHE] [-T SRC_CACHE] [-O OUTPUT_FMT] [-B BACKING_FILE] [-o OPTIONS] [-l SNAPSHOT_PARAM] [-S SPARSE_SIZE] [-r RATE_LIMIT] [-m NUM_COROUTINES] [-W] FILENAME [FILENAME2 [...]] OUTPUT_FILENAME Convert the disk image FILENAME or a snapshot SNAPSHOT_PARAM to disk image OUTPUT_FILENAME using format OUTPUT_FMT. It can be optionally compressed (-c option) or use any format specific options like encryption (-o option).
Only the formats qcow and qcow2 support compression. The compression is read-only. It means that if a compressed sector is rewritten, then it is rewritten as uncompressed data.
Image conversion is also useful to get smaller image when using a growable format such as qcow: the empty sectors are detected and suppressed from the destination image.
SPARSE_SIZE indicates the consecutive number of bytes (defaults to 4k) that must contain only zeros for qemu-img to create a sparse image during conversion. If SPARSE_SIZE is 0, the source will not be scanned for unallocated or zero sectors, and the destination image will always be fully allocated.
You can use the BACKING_FILE option to force the output image to be created as a copy on write image of the specified base image; the BACKING_FILE should have the same content as the input's base image, however the path, image format, etc may differ.
If a relative path name is given, the backing file is looked up relative to the directory containing OUTPUT_FILENAME.
If the -n option is specified, the target volume creation will be skipped. This is useful for formats such as rbd if the target volume has already been created with site specific options that cannot be supplied through qemu-img.
Out of order writes can be enabled with -W to improve performance. This is only recommended for preallocated devices like host devices or other raw block devices. Out of order write does not work in combination with creating compressed images.
NUM_COROUTINES specifies how many coroutines work in parallel during the convert process (defaults to 8).
Use of --bitmaps requests that any persistent bitmaps present in the original are also copied to the destination.  If any bitmap is inconsistent in the source, the conversion will fail unless --skip-broken-bitmaps is also specified to copy only the consistent bitmaps.
create [--object OBJECTDEF] [-q] [-f FMT] [-b BACKING_FILE] [-F BACKING_FMT] [-u] [-o OPTIONS] FILENAME [SIZE] Create the new disk image FILENAME of size SIZE and format FMT. Depending on the file format, you can add one or more OPTIONS that enable additional features of this format.
If the option BACKING_FILE is specified, then the image will record only the differences from BACKING_FILE. No size needs to be specified in this case. BACKING_FILE will never be modified unless you use the commit monitor command (or qemu-img commit).
If a relative path name is given, the backing file is looked up relative to the directory containing FILENAME.
Note that a given backing file will be opened to check that it is valid. Use the -u option to enable unsafe backing file mode, which means that the image will be created even if the associated backing file cannot be opened. A matching backing file must be created or additional options be used to make the backing file specification valid when you want to use an image created this way.
The size can also be specified using the SIZE option with -o, it doesn't need to be specified separately in this case.
dd [--image-opts] [-U] [-f FMT] [-O OUTPUT_FMT] [bs=BLOCK_SIZE] [count=BLOCKS] [skip=BLOCKS] if=INPUT of=OUTPUT dd copies from INPUT file to OUTPUT file converting it from FMT format to OUTPUT_FMT format.
The data is by default read and written using blocks of 512 bytes but can be modified by specifying BLOCK_SIZE. If count=BLOCKS is specified dd will stop reading input after reading BLOCKS input blocks.
The size syntax is similar to dd(1)'s size syntax.
info [--object OBJECTDEF] [--image-opts] [-f FMT] [--output=OFMT] [--backing-chain] [-U] FILENAME Give information about the disk image FILENAME. Use it in particular to know the size reserved on disk which can be different from the displayed size. If VM snapshots are stored in the disk image, they are displayed too.
If a disk image has a backing file chain, information about each disk image in the chain can be recursively enumerated by using the option --backing-chain.
For instance, if you have an image chain like:
base.qcow2 <- snap1.qcow2 <- snap2.qcow2
To enumerate information about each disk image in the above chain, starting from top to base, do:
qemu-img info --backing-chain snap2.qcow2
The command can output in the format OFMT which is either human or json.  The JSON output is an object of QAPI type ImageInfo; with --backing-chain, it is an array of ImageInfo objects.
--output=human reports the following information (for every image in the chain):
image  The image file name
file format The image format
virtual size The size of the guest disk
disk size How much space the image file occupies on the host file system (may be shown as 0 if this information is unavailable, e.g. because there is no file system)
cluster_size Cluster size of the image format, if applicable
encrypted Whether the image is encrypted (only present if so)
cleanly shut down This is shown as no if the image is dirty and will have to be auto-repaired the next time it is opened in qemu.
backing file The backing file name, if present
backing file format The format of the backing file, if the image enforces it
Snapshot list A list of all internal snapshots
Format specific information Further information whose structure depends on the image format.  This section is a textual representation of the respective ImageInfoSpecific* QAPI object (e.g. ImageInfoSpecificQCow2 for qcow2 images).
map [--object OBJECTDEF] [--image-opts] [-f FMT] [--start-offset=OFFSET] [--max-length=LEN] [--output=OFMT] [-U] FILENAME Dump the metadata of image FILENAME and its backing file chain. In particular, this commands dumps the allocation state of every sector of FILENAME, together with the topmost file that allocates it in the backing file chain.
Two option formats are possible.  The default format (human) only dumps known-nonzero areas of the file.  Known-zero parts of the file are omitted altogether, and likewise for parts that are not allocated throughout the chain.  qemu-img output will identify a file from where the data can be read, and the offset in the file. Each line will include four fields, the first three of which are hexadecimal numbers.  For example the first line of:
Offset          Length          Mapped to       File 0               0x20000         0x50000         /tmp/overlay.qcow2 0x100000        0x10000         0x95380000      /tmp/backing.qcow2
means that 0x20000 (131072) bytes starting at offset 0 in the image are available in /tmp/overlay.qcow2 (opened in raw format) starting at offset 0x50000 (327680).  Data that is compressed, encrypted, or otherwise not available in raw format will cause an error if human format is in use.  Note that file names can include newlines, thus it is not safe to parse this output format in scripts.
The alternative format json will return an array of dictionaries in JSON format.  It will include similar information in the start, length, offset fields; it will also include other more specific information:
• boolean field data: true if the sectors contain actual data, false if the sectors are either unallocated or stored as optimized all-zero clusters
• boolean field zero: true if the data is known to read as zero
• boolean field present: true if the data belongs to the backing chain, false if rebasing the backing chain onto a deeper file would pick up data from the deeper file;
• integer field depth: the depth within the backing chain at which the data was resolved; for example, a depth of 2 refers to the backing file of the backing file of FILENAME.
In JSON format, the offset field is optional; it is absent in cases where human format would omit the entry or exit with an error.  If data is false and the offset field is present, the corresponding sectors in the file are not yet in use, but they are preallocated.
For more information, consult include/block/block.h in QEMU's source code.
measure [--output=OFMT] [-O OUTPUT_FMT] [-o OPTIONS] [--size N | [--object OBJECTDEF] [--image-opts] [-f FMT] [-l SNAPSHOT_PARAM] FILENAME] Calculate the file size required for a new image.  This information can be used to size logical volumes or SAN LUNs appropriately for the image that will be placed in them.  The values reported are guaranteed to be large enough to fit the image.  The command can output in the format OFMT which is either human or json.  The JSON output is an object of QAPI type BlockMeasureInfo.
If the size N is given then act as if creating a new empty image file using qemu-img create.  If FILENAME is given then act as if converting an existing image file using qemu-img convert.  The format of the new file is given by OUTPUT_FMT while the format of an existing file is given by FMT.
A snapshot in an existing image can be specified using SNAPSHOT_PARAM.
The following fields are reported:
required size: 524288 fully allocated size: 1074069504 bitmaps size: 0
The required size is the file size of the new image.  It may be smaller than the virtual disk size if the image format supports compact representation.
The fully allocated size is the file size of the new image once data has been written to all sectors.  This is the maximum size that the image file can occupy with the exception of internal snapshots, dirty bitmaps, vmstate data, and other advanced image format features.
The bitmaps size is the additional size required in order to copy bitmaps from a source image in addition to the guest-visible data; the line is omitted if either source or destination lacks bitmap support, or 0 if bitmaps are supported but there is nothing to copy.
snapshot [--object OBJECTDEF] [--image-opts] [-U] [-q] [-l | -a SNAPSHOT | -c SNAPSHOT | -d SNAPSHOT] FILENAME List, apply, create or delete snapshots in image FILENAME.