2,257
edits
Changes
Jump to navigation
Jump to search
Created page with "The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them. == General format description == Most of the crto..."
The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them.
== General format description ==
Most of the crtools image files begin with 32-bit magic cookie followed by zero or more entries of the same type (not size!). Most of the entries are encoded in the Google Protocol Buffers format and each is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.
IOW image files look like
<pre>
IMAGE_FILE ::= MAGIC { ENTRY }
ENTRY ::= SIZE PAYLOAD [ EXTRA ]
PAYLOAD ::= "message encoded in ProtocolBuffer format"
EXTRA ::= "arbitrary blob, depends on the PAYLOAD contents"
MAGIC ::= "32 bit integer"
SIZE ::= "32 bit integer, equals the PAYLOAD length"
</pre>
The amount of entries in a image file depends on the type of file.
== Types of image files ==
Images encoded with ProtocolBuffers can be one of
; Array image files
: In these files the amount of entries can be any. You should read the image file up to the EOF to find out the exact number.
; Single-entry image files
: In these files exactly one entry is stored.
A file type can be guessed by the magic. The description of the entries in ProtocolBuffers language are in <type>.proto files.
{|class="wikitable sortable"
|-
| name
| type
| description
| extra payload
|-
| fdinfo || array || Open file descriptors || -
|-
| regfile || array || Paths to files opened with <code>open(2)</code> syscall || -
|-
| eventfd || array || Eventfd file information || -
|-
| eventpoll || array || Eventpoll file information || -
|-
| eventpoll-tfd || array || Target file descriptors of eventpoll fds || -
|-
| inotify-file || array || Inotify file information || -
|-
| inotify-wd || array || Watch descriptors of inotify fds || -
|-
| core || single-entry || Arch-dependent information (registers, etc.) || -
|-
| mm || single-entry || Address space generic information (segments, exe file, etc.) || -
|-
| vmas || array || Virtual mappings (<code>mmap(2)</code>) || -
|-
| pipes || array || Pipes information || -
|-
| pipes-data || array || Contents of pipes || <code>entry.bytes</code> bytes of data sitting in a pipe
|-
| fifo || array || FIFO information || -
|-
| fifo-data || array || Contents of FIFOs || same as in pipes-data
|-
| pstree || array || Process tree linkage and IDs || -
|-
| sigacts || array || Signal handling map || -
|-
| unixsk || array || Unix domain sockets || -
|-
| inetsk || array || PF_INET sockets, both IPv4 and IPv6 || -
|-
| sk-queues || array || Contents of socket queues || <code>entry.length</code> bytes of data, one entry per packet
|-
| itimers || array || Interval timers state || -
|-
| creds || single-entry || Task credentials: uids, gids, caps, etc. || -
|-
| fs || single-entry || Chroot and chdir information || -
|-
| path-remap || array || File paths remaps || -
|-
| ghost-file || single-entry || Ghost files (those, not visible from FS, but still used by tasks) || Right after the entry up to the EOF goes the contents of the file
|-
| tcp-stream || single-entry || TCP connection state (including data in queues) || -
|-
| mountpoints || array || Mountpoints information || -
|}
There are, however, images which are not in ProtocolBuffers.
; Memory dumps
: These files contain memory dumps. The format is
<pre>
IMAGE ::= MAGIC [ ADDRESS DATA ]
ADDRESS ::= "64-bit virtual address"
DATA ::= "4K bytes blob (i.e. -- memory page)"
</pre>
== General format description ==
Most of the crtools image files begin with 32-bit magic cookie followed by zero or more entries of the same type (not size!). Most of the entries are encoded in the Google Protocol Buffers format and each is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.
IOW image files look like
<pre>
IMAGE_FILE ::= MAGIC { ENTRY }
ENTRY ::= SIZE PAYLOAD [ EXTRA ]
PAYLOAD ::= "message encoded in ProtocolBuffer format"
EXTRA ::= "arbitrary blob, depends on the PAYLOAD contents"
MAGIC ::= "32 bit integer"
SIZE ::= "32 bit integer, equals the PAYLOAD length"
</pre>
The amount of entries in a image file depends on the type of file.
== Types of image files ==
Images encoded with ProtocolBuffers can be one of
; Array image files
: In these files the amount of entries can be any. You should read the image file up to the EOF to find out the exact number.
; Single-entry image files
: In these files exactly one entry is stored.
A file type can be guessed by the magic. The description of the entries in ProtocolBuffers language are in <type>.proto files.
{|class="wikitable sortable"
|-
| name
| type
| description
| extra payload
|-
| fdinfo || array || Open file descriptors || -
|-
| regfile || array || Paths to files opened with <code>open(2)</code> syscall || -
|-
| eventfd || array || Eventfd file information || -
|-
| eventpoll || array || Eventpoll file information || -
|-
| eventpoll-tfd || array || Target file descriptors of eventpoll fds || -
|-
| inotify-file || array || Inotify file information || -
|-
| inotify-wd || array || Watch descriptors of inotify fds || -
|-
| core || single-entry || Arch-dependent information (registers, etc.) || -
|-
| mm || single-entry || Address space generic information (segments, exe file, etc.) || -
|-
| vmas || array || Virtual mappings (<code>mmap(2)</code>) || -
|-
| pipes || array || Pipes information || -
|-
| pipes-data || array || Contents of pipes || <code>entry.bytes</code> bytes of data sitting in a pipe
|-
| fifo || array || FIFO information || -
|-
| fifo-data || array || Contents of FIFOs || same as in pipes-data
|-
| pstree || array || Process tree linkage and IDs || -
|-
| sigacts || array || Signal handling map || -
|-
| unixsk || array || Unix domain sockets || -
|-
| inetsk || array || PF_INET sockets, both IPv4 and IPv6 || -
|-
| sk-queues || array || Contents of socket queues || <code>entry.length</code> bytes of data, one entry per packet
|-
| itimers || array || Interval timers state || -
|-
| creds || single-entry || Task credentials: uids, gids, caps, etc. || -
|-
| fs || single-entry || Chroot and chdir information || -
|-
| path-remap || array || File paths remaps || -
|-
| ghost-file || single-entry || Ghost files (those, not visible from FS, but still used by tasks) || Right after the entry up to the EOF goes the contents of the file
|-
| tcp-stream || single-entry || TCP connection state (including data in queues) || -
|-
| mountpoints || array || Mountpoints information || -
|}
There are, however, images which are not in ProtocolBuffers.
; Memory dumps
: These files contain memory dumps. The format is
<pre>
IMAGE ::= MAGIC [ ADDRESS DATA ]
ADDRESS ::= "64-bit virtual address"
DATA ::= "4K bytes blob (i.e. -- memory page)"
</pre>