Sep 12 – 14, 2022
Europe/Dublin timezone

Bringing up FUSE mounts C/R support

Sep 14, 2022, 1:00 PM
"Herbert" (Clayton Hotel on Burlington Road)


Clayton Hotel on Burlington Road

Containers and Checkpoint/Restore MC Containers and Checkpoint/Restore MC


Alexander Mikhalitsyn (Virtuozzo)


Bringing up FUSE mounts C/R support


Each filesystem support in CRIU brings their own problems. Block-device based filesystems
comparably easy to handle, we just need to save mount options and use it at the restore stage,
it is also possible to provide such filesystems as an external mounts. Some virtual filesystems
should be handled specially, for instance for tmpfs we care about saving entire fs content, for
overlayfs we have to do some special processing to resolve source directories paths. But NFS
and FUSE filesystems is totally different story. This talk is aimed to cover and discuss about
the ways and problems which connected with FUSE filesystem support. There are some parallels
between support for NFS (which is present in CRIU OpenVZ fork), but generally approach is different.
Right now we don't have ready-to-go solution and support for FUSE C/R, this work was started by
Vitaly Ostrosablin and me this year. We have ideas and PoC solutions for some of most important
technical problems that comes into mind there but we also have things to discuss with the community.



The main problem with FUSE filesystem support is that FUSE tie up different
kernel objects (fuse mount, fuse daemon task, fuse control device, fuse file descriptors,
fuse file memory mappings). This is very challenging from the CRIU side because we have
special order of kernel resources restoration. And this is not a question of our choice.

How CRIU handles files C/R?

First of all, CRIU restores all the mounts. Tasks are restored lately. Why?
1. to have ability to restore file memory mappings at the same time as we restore
process tree (to get VMAs inherited) [2]
2. To restore memory mappings for files we need to have mount roots descriptors ready to use

Finally, we have a strict order mounts -> tasks and mappings. But FUSE breaks this logic totally.
We need to have a FUSE daemon ready at the same time when we creating mount. But we can't do that,
because fuse daemon task may use some external resources like network sockets, pipes, file descriptors
opened from another mounts.

What we can do with that?

Idea is fairly simple and elegant. Let's create fake fuse daemon and use it for mount fuse rarely,
then, once we are ready we can replace fuse daemon by the original one. Good news here is that
kernel allows to do that without any changes.


Next challenge. Dumping fuse file descriptors info with frozen network



  • [1] Original issue
  • [2]
I agree to abide by the anti-harassment policy Yes

Primary author

Alexander Mikhalitsyn (Virtuozzo)


Vitaly Ostrosablin

Presentation materials

Diamond Sponsor

Platinum Sponsors

Gold Sponsors

Silver Sponsors

Speaker Gift Sponsor

Catchbox Sponsor

Video Recording Sponsor

Livestream Sponsor

T-Shirt Sponsor

Conference Services Provided by