37
edits
Changes
Jump to navigation
Jump to search
Line 192:
Line 192: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 257:
Line 299: +
Add detached mounts idea
* Mentor: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
* Mentor: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
* Suggested by: Adrian Reber <areber@redhat.com>
* Suggested by: Adrian Reber <areber@redhat.com>
=== Files on detached mounts ===
'''Summary:''' Initial support of open files on "detached" mounts
When criu dumps a process with an open fd on a file, it gets the mount identifier (mnt_id) via /proc/<pid>/fdinfo/<fd>, so that criu knows from which exact mount the file was initially opened. This way criu can restore this fd by opening the same exact file from topologically the same mount in restored mount tree.
Restoring fd from the right mount can be important in different cases, for instance if the process would later want to resolve paths relative to the fd, and obviously resolving from the same file on different mount can lead to different resolved paths, or if the process wants to check path to the file via /proc/<pid>/fd/<fd>.
But we have a problem finding on which mount we need to reopen the file at restore if we only know mnt_id but can't find this mnt_id in /proc/<pid>/mountinfo.
Mountinfo file shows the mount tree topology of current mntns: parent - child relations, sharing group information, mountpoint and fs root information. And if we don't see mnt_id in it we don't know anything about this mount.
This can happen in two cases
* 1) external mount or file - if file was opened from e.g. host it's mount would not be visible in container mountinfo
* 2) mount was lazily unmounted
In case of 1) we have criu options to help criu handle external dependencies.
In case of 2) or no options provided criu can't resolve mnt_id in mountinfo and criu fails.
'''Solution:'''
We can handle 2) with: resolving major/minor via fstat, using name_to_handle_at and open_by_handle_at to open same file on any other available mount from same superblock (same major/minor) in container. Now we have fd2 of the same file as fd, but on existing mount we can dump it as usual instead, and mark it as "detached" in image, now criu on restore knows where to find this file, but instead of just opening fd2 from actually restored mount, we create a temporary bindmount which is lazy unmounted just after open making the file appear as a file on detached mount.
Known problems with this approach:
* Stat on btrfs gives wrong major/minor
* file handles does not work everywhere
* file handles can return fd2 on deleted file or on other hardlink, this needs special handling.
Additionally (optional part):
We can export real major/minor in fdinfo (kernel).
We can think of new kernel interface to get mount's major/minor and root (shift from fsroot) for detached mounts, if we have it we don't need file handle hack to find file on other mount (see fsinfo or getvalues kernel patches in LKML, can we add this info there?).
'''Details:'''
* Skill level: intermediate
* Language: C
* Mentor: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
* Suggested by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
== Suspended project ideas ==
== Suspended project ideas ==
* Mentor: Pavel Emelianov <xemul@virtuozzo.com>
* Mentor: Pavel Emelianov <xemul@virtuozzo.com>
* Suggested by: Pavel Emelianov <xemul@virtuozzo.com>
* Suggested by: Pavel Emelianov <xemul@virtuozzo.com>
[[Category:GSoC]]
[[Category:GSoC]]
[[Category:Development]]
[[Category:Development]]