Changes

657 bytes added ,  12:48, 23 February 2023
m
→‎Chunked ghost files: describe --ghost-fiemap
Line 36: Line 36:  
First, we [[dumping files|get the files]] from the target process via unix socket. Then for each of them get the file's name via /proc by calling <code>readlink</code> on the /proc/self/fd/$fd path. It's important to note, that we readlink ''self'' FD to get the file's name we can work with. Next we <code>fstat()</code> the respective self file descriptor.
 
First, we [[dumping files|get the files]] from the target process via unix socket. Then for each of them get the file's name via /proc by calling <code>readlink</code> on the /proc/self/fd/$fd path. It's important to note, that we readlink ''self'' FD to get the file's name we can work with. Next we <code>fstat()</code> the respective self file descriptor.
   −
If the <code>st_nlink</code> field is zero, then the file is fully deleted from the system. Since no filesystems allow to recreate the name of such files, we have no other choice than to store the file itself into images. So we generate a so called ''ghost file'' in the image directory and copy the file contents into it. Since the file is taken into the images, it would be good if the file size is not huge. By default CRIU dumps ghost files at most 1Mb in size. But with the option <code>--ghost-limit</code> this limit can be changed.
+
If the <code>st_nlink</code> field is zero, then the file is fully deleted from the system. Since no filesystems allow to recreate the name of such files, we have no other choice than to store the file itself into images. So we generate a so called ''ghost file'' in the image directory and copy the file contents into it. Since the content of the file is saved into images, CRIU has a limit for a maximum file size it can checkpoint. By default, this limit is set to 1Mb but it can be changed with the <code>--ghost-limit</code> option.
    
But what happens if the link count is not zero. Then we should check than the name we got from proc is the one with which we can see this file. So we call <code>stat()</code> on this name and compare <code>st_dev</code> and <code>st_inode</code> fields of it with those obtained from the fstat() call earlier. If they match the file is alive and we can just dump its name. If they don't the name we got references some other file and we fail the dump. This can be handled, but this situation is quite rare so we decided to implement support for it later.  
 
But what happens if the link count is not zero. Then we should check than the name we got from proc is the one with which we can see this file. So we call <code>stat()</code> on this name and compare <code>st_dev</code> and <code>st_inode</code> fields of it with those obtained from the fstat() call earlier. If they match the file is alive and we can just dump its name. If they don't the name we got references some other file and we fail the dump. This can be handled, but this situation is quite rare so we decided to implement support for it later.  
Line 43: Line 43:     
Please note that a file may have been opened by many removed names, and for each a link-remap name should point to the same file, so while dumping and restoring CRIU keeps track of those names to inode mappings.
 
Please note that a file may have been opened by many removed names, and for each a link-remap name should point to the same file, so while dumping and restoring CRIU keeps track of those names to inode mappings.
 +
 +
=== Chunked ghost files ===
 +
 +
When CRIU checkpoints an invisible (ghost) file with size larger than 12MB, it would try to reduce the size of the corresponding image by seeking for holes (e.g., in sparse files). This approach allows CRIU to save the content of the file into a set of chunks and skip over the "empty" space in a file by keeping track of the offsets.
 +
 +
However, determining the offsets in highly sparse file might encounter a significant amount of expensive system calls. In order to reduce the overhead of dumping such ghost files, CRIU supports the <code>--ghost-fiemap</code> option that uses an optimized algorithm based on the fiemap ioctl.
    
=== Virtual filesystems ===
 
=== Virtual filesystems ===
277

edits