Jump to: navigation, search


1,940 bytes added, 10:57, 5 September 2014
no edit summary
== Dump Hardness in dumping and restoring of fsnotify == Fsnotify are implemented quite straightforth -- we can fetch watchees by their handled from procfs output:  pos: 0 flags: 02000000 inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d so that on dump we can remember a watchee file handler and open it back on restore retrieving path from file descriptorlink provided by procfs. This all works just fine until watchees are represented as children of another watch descriptor. Consider one has adirectory '''dir''' and two files under it '''a''' and '''b''':  dir `- a `- b and a program sets up fsnotify mark on every file entry, i.e. on '''dir''' itself and both files. Then imaginea program open both '''a''' and '''b''' and then unlink them. This action generates notify events which a programmay or may not read yet (thus events queue is not empty) but a user start dumping procedure. Because kernel hasnot yet any API to peek events from queue (note the ''peek'' here means to read events without removing themfrom the queue) we either should ignore the events or refuse to dump. Refusing dumping might be an option but due to current CRIU design it turns out that we might stuck in situationwhere any attempt to dump will force CRIU to generate events itself leading to endless cycle. This is mostly becauseof that named ''ghost'' files. The ''ghost'' files are the files which were removed by an application but its filedescriptor is still alive. For such scenario we generate a hardlink to the deleted file at moment of dumping whichof course generates notify events. Almost the same situation happens on restore procedure -- ''ghost'' files get unlinked which cause kernel togenerate events. So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queueson dump and live with the fact that we're generating own events ==on restore.

Navigation menu