5
edits
Changes
mLine 1:
Line 1: + + Line 5:
Line 7: − + Line 41:
Line 43: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
This article describes what CRIU does to make sure it restores the correct set of files and how this file validation is implemented in CRIU. This project was completed under the [https://summerofcode.withgoogle.com/projects/#5773537320632320 GSoC 2020 program].
This article describes what CRIU does to make sure it restores the correct set of files and how this file validation is implemented in CRIU. This project was completed under the [https://summerofcode.withgoogle.com/projects/#5773537320632320 GSoC 2020 program].
Note: This is NOT merged to CRIU, see https://github.com/checkpoint-restore/criu/pull/1148
== The previous implementation ==
== The previous implementation ==
== The current implementation ==
== The current implementation ==
The file size method should be a preliminary method, if it fails there’s no need to do any of the more intensive checks and immediately give out an error and stop restoring. Stronger checks are used only if it passes.
The file size method is used as a preliminary method, if it fails there’s no need to do any of the more intensive checks, instead it will immediately give out an error and stop restoring. Stronger checks are used only if it passes.
The simplest and strongest check is to calculate the checksum for the entire file but this would be very intensive for large files and therefore not always feasible. A reasonable compromise would be to calculate the checksum only for certain parts of the file. This is the checksum method and it is one of the two methods that have been implemented in CRIU.
The simplest and strongest check is to calculate the checksum for the entire file but this would be very intensive for large files and therefore not always feasible. A reasonable compromise would be to calculate the checksum only for certain parts of the file. This is the checksum method and it is one of the two methods that have been implemented in CRIU.
To explicitly use only the file size check all the time, the following command-line option can be used: <code>--file-validation filesize</code> (This is the fastest and least intensive check).
To explicitly use only the file size check all the time, the following command-line option can be used: <code>--file-validation filesize</code> (This is the fastest and least intensive check).
== Performance impact ==
The values shown below are the average times it took to finish the ZDTM tests over multiple runs, and are only to indicate the impact each method has in general.
Each test has 3 files (Of sizes: 0.09 MB, 2 MB and 0.17 MB approximately) and each test is run 3 times (In Host, Namespace and User Namespace). For each file the checksum/build-ID is obtained twice (During dump and restore) therefore the function to find checksum/build-ID is called 18 times overall per test.
For reference, these tests were run on tmpfs (To remove any disk latency) and on an undervolted i5 4800H.
{| class="wikitable" style="text-align: center;
|+zdtm/transition/shmem:
|-
|File Size
|3.782s
|-
|Build-ID
|4.153s (~9% increase)
|-
|Checksum (First 1024 bytes)
|4.465s (~18% increase)
|-
|Checksum (Entire File)
|4.722s (~24% increase)
|-
|Checksum (Every 1024th byte)
|4.498s (~19% increase)
|}
{| class="wikitable" style="text-align: center;
|+zdtm/static/maps04:
|-
|File Size
|35.317s
|-
|Build-ID
|35.720s (~1% increase)
|-
|Checksum (First 1024 bytes)
|35.919s (~2% increase)
|-
|Checksum (Entire File)
|36.679s (~4% increase)
|-
|Checksum (Every 1024th byte)
|36.476s (~3% increase)
|}
== Scope for improvement and future work ==
== Scope for improvement and future work ==
* Calculating the checksum can be made faster by using a lookup table.
* Calculating the checksum can be made faster by using a lookup table.
[[Category:Files]]
[[Category:Under the hood]]
[[Category:Under the hood]]