Fsnotify - Revision history

Kir: /* See also / :)

2016-11-18T02:36:51Z

Xemul: /* Chopping the knot */

2016-11-17T08:51:40Z

Chopping the knot

Xemul: cat files

2015-02-26T15:45:07Z

cat files

Xemul at 07:21, 3 December 2014

2014-12-03T07:21:03Z

Cyrillos at 11:05, 5 September 2014

2014-09-05T11:05:34Z

Cyrillos at 10:57, 5 September 2014

2014-09-05T10:57:24Z

Cyrillos at 10:13, 5 September 2014

2014-09-05T10:13:42Z

Cyrillos: Created page with "Dump and restore of fsnotify events"

2014-09-05T10:13:20Z

Created page with "Dump and restore of fsnotify events"

New page

Dump and restore of fsnotify events

@@ Line 45: / Line 45: @@
 == See also ==
-[[Irmap]]
+* [[Irmap]]
 [[Category: Under the hood]]
 [[Category: Files]]

@@ Line 43: / Line 43: @@
 both ways require significant rework of CRIU design so for a while we simply print out a warning if fsnotify queue is not empty and continue processing.
 [[Category: Under the hood]]
 [[Category: Files]]

← Older revision		Revision as of 15:45, 26 February 2015
Line 45:		Line 45:

	[[Category: Under the hood]]		[[Category: Under the hood]]
		+	[[Category: Files]]

← Older revision		Revision as of 07:21, 3 December 2014
Line 43:		Line 43:

	both ways require significant rework of CRIU design so for a while we simply print out a warning if fsnotify queue is not empty and continue processing.		both ways require significant rework of CRIU design so for a while we simply print out a warning if fsnotify queue is not empty and continue processing.
		+
		+	[[Category: Under the hood]]

← Older revision		Revision as of 11:05, 5 September 2014
Line 34:		Line 34:
	So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queues		So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queues
	on dump and live with the fact that we're generating own events on restore.		on dump and live with the fact that we're generating own events on restore.
		+
		+	== Chopping the knot ==
		+
		+	Here are possible ways to resolve the situation
		+
		+	* when dumping files gather fsnotify and ghost file descriptors into separate lists and dump them at the very late stage; then read out notify events from fsnotify descriptors
		+	* when restoring files collect fsnotify descriptors into a root criu task deferring theis restore until all other files (from every child process) are restored; then restore notifies and read out all generated events
		+
		+	both ways require significant rework of CRIU design so for a while we simply print out a warning if fsnotify queue is not empty and continue processing.

← Older revision		Revision as of 10:57, 5 September 2014
Line 1:		Line 1:
−	== ~~Dump~~ and restore of fsnotify events ==	+	== 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 descriptor
		+	link provided by procfs.
		+
		+	This all works just fine until watchees are represented as children of another watch descriptor. Consider one has a
		+	directory '''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 imagine
		+	a program open both '''a''' and '''b''' and then unlink them. This action generates notify events which a program
		+	may or may not read yet (thus events queue is not empty) but a user start dumping procedure. Because kernel has
		+	not yet any API to peek events from queue (note the ''peek'' here means to read events without removing them
		+	from 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 situation
		+	where any attempt to dump will force CRIU to generate events itself leading to endless cycle. This is mostly because
		+	of that named ''ghost'' files. The ''ghost'' files are the files which were removed by an application but its file
		+	descriptor is still alive. For such scenario we generate a hardlink to the deleted file at moment of dumping which
		+	of course generates notify events.
		+
		+	Almost the same situation happens on restore procedure -- ''ghost'' files get unlinked which cause kernel to
		+	generate events.
		+
		+	So until redesign of the dumping/restore procedure for fsnotify system we have to ignore nonempty notify queues
		+	on dump and live with the fact that we're generating own events on restore.

← Older revision		Revision as of 10:13, 5 September 2014
Line 1:		Line 1:
−	Dump and restore of fsnotify events	+	== Dump and restore of fsnotify events ==