Irmap - Revision history

Radostin: /* OverlayFS */

2023-12-20T17:22:00Z

OverlayFS

Radostin: /* Problem */

2018-04-29T10:56:08Z

Problem

Xemul at 15:23, 24 January 2017

2017-01-24T15:23:46Z

Xemul at 08:51, 17 November 2016

2016-11-17T08:51:55Z

Xemul: Created page with "== Problem == How having an inode number and device of a file get its path back? This problem appears when dumping various notifies objects like inotify or fanotify. Those ar..."

2015-09-10T18:53:03Z

Created page with "== Problem == How having an inode number and device of a file get its path back? This problem appears when dumping various notifies objects like inotify or fanotify. Those ar..."

New page

== Problem ==

How having an inode number and device of a file get its path back? This problem appears when dumping various notifies objects like inotify or fanotify. Those are put on an inode (that is looked up by a path) and after it the path string is forgotten.

CRIU uses the empiric knowledge where *notify-s are typically put by programs (config files and alike) and does filesystem tree scan to find out the name by the inode number. The engine is caller ''irmap'' which stands for Inode Reverse MAP. The irmap cache recursively scans the tree starting from "known" locations and remembers all the name-inode pairs it meets. If we later try to irmap some inode which was met during the first scan, no additional FS access would occur, irmap would just report the name back.

== Caching the irmap cache ==

Since this FS scan can be quite long, this is recommended to be done while tasks are not frozen. So the irmap cache fill is also started on the pre-dump operation, when tasks are not frozen. After the scan the cache is stored in the working dir under the irmap-cache.img name. When CRIU's next pre-dump or final dump is performed, the irmap cache is read back and when required the cached entries are re-validated individually, w/o the full FS re-scan.

== Other solutions? ==

We're currently unaware of any :(

[[Category: Under the hood]]
[[Category: Thinkers]]

@@ Line 15: / Line 15: @@
 == OverlayFS ==
-[https://github.com/xemul/criu/issues/136 Irmap doesn't work on this FS]
+[https://github.com/checkpoint-restore/criu/issues/136 Irmap doesn't work on this FS]
 [[Category: Under the hood]]
 [[Category: Thinkers]]
 [[Category: Fly in the ointment]]

← Older revision		Revision as of 08:51, 17 November 2016
Line 15:		Line 15:
	[[Category: Under the hood]]		[[Category: Under the hood]]
	[[Category: Thinkers]]		[[Category: Thinkers]]
		+	[[Category: Fly in the ointment]]

@@ Line 3: / Line 3: @@
 How having an inode number and device of a file get its path back? This problem appears when dumping various notifies objects like inotify or fanotify. Those are put on an inode (that is looked up by a path) and after it the path string is forgotten.
-CRIU uses the empiric knowledge where *notify-s are typically put by programs (config files and alike) and does filesystem tree scan to find out the name by the inode number. The engine is caller ''irmap'' which stands for Inode Reverse MAP. The irmap cache recursively scans the tree starting from "known" locations and remembers all the name-inode pairs it meets. If we later try to irmap some inode which was met during the first scan, no additional FS access would occur, irmap would just report the name back.
+CRIU uses the empiric knowledge where *notify-s are typically put by programs (config files and alike) and does filesystem tree scan to find out the name by the inode number. The engine is caller ''irmap'' which stands for '''Inode Reverse MAP'''. The irmap cache recursively scans the tree starting from "known" locations and remembers all the name-inode pairs it meets. If we later try to irmap some inode which was met during the first scan, no additional FS access would occur, irmap would just report the name back.
 == Caching the irmap cache ==