2,257
edits
Changes
+ more info 2
| crtools || Lazy migration using userfaultd || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.
| crtools || Lazy migration using userfaultd || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.
|-
|-
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.
|-
|-
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes to log files slow things down ([[Logging]])
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.
|-
|-
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are placed w/o any logic. Need to improve that ... somehow.
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.
|-
|-
| crtools || Support OFD posix locks || easy || - ||
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.
|-
|-
| crtools || Optimize kcmp calls || medium || - || For fs/fdt/vm/etc we can pre-generate ID based on objects that live on them. If pre-ID matches, then call kcmp.
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.
|-
|-
| crtools || Shmem changes tracking || medium || - ||
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.
|-
|-
| crtools || Page transfer filters || medium || - || Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?
|-
|-
| crtools || FUSE mount points || hard || - ||
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.
|-
|-
| crtools || 32-bit tasks || hard || Cyrill ||
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.
|-
|-
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev ||
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those.
|-
|-
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Need (probably) some way to alter what is being restored. Usage example -- change the IP address of sockets from task above.
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.
|-
|-
| crtools || TCP socket migration with changed IP || medium || - || [[CRIT]] it might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks, but this might make sense.
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.
|-
|-
| crtools || [[Applying images]] || hard || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). E.g. -- repopulate fdtable according to data from image. Another use-case -- when doing partial migration we'll need to modify one part to switch from pipes to sockets
| crtools || [[Applying images]] || hard || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.
|-
|-
| crtools || Partial migration || hard || - || migrate some tasks while proxying IPC to existing others (pipes->sockets, etc.)
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.
|-
|-
| crtools || Shared objects (mm/fs) support || medium || - || Now we have the kcmp syscall and can do it. The first candidate is mm sharing, as we do know, that MySQL does so sometimes.
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.
|-
|-
| crtools || Smart paths resolution || hard || - || Need a way to resolve paths to overmounted files. There are two ways: 1. Move mounts, that overlap the desired path temprarily. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is not [[alive|invisible files]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.
|-
|-
| kernel/crtools || TCP repair fixes || hard || - || [[TCP repair TODO]]
| kernel/crtools || TCP repair fixes || hard || - || [[TCP repair TODO]]