Difference between revisions of "Filesystems pecularities"
(Added btrfs problem) |
m (→BTRFS) |
||
| Line 7: | Line 7: | ||
When we <code>stat()</code> a file we can get on which device it resides by checking the <code>st_dev</code> value. However, kernel exposes the device value in some more places. In particular, the device is shown in the <code>/proc/$pid/[mounts|mountinfo]</code> files and in the <code>/proc/$pid/s?maps</code> ones. Moreover, the sock-diag subsystem recently added into the kernel, reveals the device (and inode) on which a unix socket is bound. | When we <code>stat()</code> a file we can get on which device it resides by checking the <code>st_dev</code> value. However, kernel exposes the device value in some more places. In particular, the device is shown in the <code>/proc/$pid/[mounts|mountinfo]</code> files and in the <code>/proc/$pid/s?maps</code> ones. Moreover, the sock-diag subsystem recently added into the kernel, reveals the device (and inode) on which a unix socket is bound. | ||
| − | The problem with btrfs is that it substitutes the real device number with a virtual one in the <code>stat()</code> system call. And once we get this value we cannot compare it to any other device number obtained from other sources, they will | + | The problem with btrfs is that it substitutes the real device number with a virtual one in the <code>stat()</code> system call. And once we get this value we cannot compare it to any other device number obtained from other sources, they will always differ (these virtual device numbers are unique). |
| − | In order to address this issue, CRIU performs path-to-device resolution in user-space by analysing the information obtained from the <code>/proc/$pid/mountinfo</code> files. | + | In order to address this issue, CRIU performs path-to-device resolution in user-space by analysing the information obtained from the <code>/proc/$pid/mountinfo</code> files. The routine in question is <code>mount.c:phys_stat_resolve_dev()</code>. |
== NFS == | == NFS == | ||
Revision as of 14:59, 21 August 2014
"All filesystems are equal, but some filesystems are more equal than others."
This page describes how different different filesystems are and how this affects CRIU dump (and restore) process.
BTRFS
When we stat() a file we can get on which device it resides by checking the st_dev value. However, kernel exposes the device value in some more places. In particular, the device is shown in the /proc/$pid/[mounts|mountinfo] files and in the /proc/$pid/s?maps ones. Moreover, the sock-diag subsystem recently added into the kernel, reveals the device (and inode) on which a unix socket is bound.
The problem with btrfs is that it substitutes the real device number with a virtual one in the stat() system call. And once we get this value we cannot compare it to any other device number obtained from other sources, they will always differ (these virtual device numbers are unique).
In order to address this issue, CRIU performs path-to-device resolution in user-space by analysing the information obtained from the /proc/$pid/mountinfo files. The routine in question is mount.c:phys_stat_resolve_dev().