Changes

So after <code>open()</code> (or some other, see below) system call there will be this chain in the memory

So after <code>open()</code> (or some other, see below) system call there will be this chain in the memory

[[File:Dumping_files-001.svg|thumb|upright=2|center]]

          | File Descriptors Table (FDT) |

          +------------------------------+

          |   |  | 2 |     ...    |  |

The File object can be referenced by more than on FDT, e.g. when a task calls <code>fork()</code> the child one gets new FDT, but it references the same Files as the parent does, i.e. Files become shared objects.

The File object can be referenced by more than on FDT, e.g. when a task calls <code>fork()</code> the child one gets new FDT, but it references the same Files as the parent does, i.e. Files become shared objects.

The Inode object is also interesting. First of all, remember that in Linux file descriptors can be obtained not only by the <code>open()</code> system call, but also by <code>pipe()</code> and <code>socket()</code> and a bunch of Linux-specific <code>epoll_create</code>, <code>signalfd</code> and others. So when serving ''this'' Linux would anyway create the mentioned above chain of File-Dentry-Inode objects, but the Inode one will be different for different calls. And CRIU knows this all and acts respectively :)

The Inode object is also interesting. First of all, remember that in Linux file descriptors can be obtained not only by the <code>open()</code> system call, but also by <code>pipe()</code> and <code>socket()</code> and a bunch of Linux-specific <code>epoll_create</code>, <code>signalfd</code> and others. So when serving ''this'' Linux would anyway create the mentioned above chain of File-Dentry-Inode objects, but the Inode one will be different for different calls. And CRIU knows this all and acts respectively :)

=== Files themselves ===

=== Files themselves ===

Fore the sake of simplicity CRIU doesn't introduce separate states for Files, Dentries and Inodes leaving it to the kernel. Instead each this triplet is treated as one object and for every Inode type (file, pipe, socket, etc.) separate image is introduced. Thus CRIU has

For the sake of simplicity, CRIU doesn't introduce separate states for Files, Dentries and Inodes, leaving it to the kernel. Instead, each triplet is treated as one object and for every Inode type (file, pipe, socket, etc.) separate image is introduced. Thus CRIU has

* reg-files.img for regular files, that are created by open() call

* reg-files.img for regular files, that are created by open() call

* etc.

* etc.

In each of this files info about File and Inode of respective file is preserved. Dentry information is effectively stored there for regular files only -- the file's ''path''.

 

In each of these image files is preserved appropriate information about File and Inode of respective file. Dentry information is effectively stored for regular files only -- the file's ''path''.

== How CRIU gets the information to dump ==

== How CRIU gets the information to dump ==

=== Files sharing ===

=== Files sharing ===

In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU uses the <code>kcmp</code> system call.

In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU [[Kcmp trees|uses]] the <code>kcmp</code> system call.

=== Determining Inode type ===

=== Determining Inode type ===

Getting the Inode state is specific to Inode. CRIU uses the following sources of information:

Getting the Inode state is specific to Inode. CRIU uses the following sources of information:

# Date from ''/proc/$pid/fdinfo/$fd/''

# Data from ''/proc/$pid/fdinfo/$fd/''

# Link target of ''/proc/$pid/fd/$fd/'' link

# Link target of ''/proc/$pid/fd/$fd/'' link

# Inode-specific ioctl()-s

# Inode-specific ioctl()-s

# read/recv/tee-s to fetch data from descriptor (pipe data, socket queues)

# Fetch data directly from FD with recv + MSG_PEEK for socket queues and tee for pipes/fifos

# sock_diag info to get info about sockets

# Info from sock_diag modules to get info about sockets

[[Category:Under the hood]]

[[Category:Under the hood]]