Dumping files - Revision history

Radostin: /* Files themselves */

2018-09-13T12:11:59Z

Files themselves

Xemul at 12:55, 13 July 2017

2017-07-13T12:55:23Z

Xemul: +cat files

2015-02-26T15:44:19Z

+cat files

Cyrillos at 18:05, 3 December 2014

2014-12-03T18:05:28Z

Cyrillos at 10:02, 3 December 2014

2014-12-03T10:02:50Z

Cyrillos at 09:49, 3 December 2014

2014-12-03T09:49:25Z

Xemul: /* State of File and Inode */

2014-12-01T11:54:07Z

State of File and Inode

Xemul at 11:52, 1 December 2014

2014-12-01T11:52:47Z

Xemul at 11:52, 1 December 2014

2014-12-01T11:52:29Z

Xemul at 11:51, 1 December 2014

2014-12-01T11:51:56Z

@@ Line 39: / Line 39: @@
 === Files themselves ===
-Fore the sake of simplicity CRIU doesn't introduce separate states for Files, Dentries and Inodes leaving it to the kernel. Instead each this triplet is treated as one object and for every Inode type (file, pipe, socket, etc.) separate image is introduced. Thus CRIU has
+For the sake of simplicity, CRIU doesn't introduce separate states for Files, Dentries and Inodes, leaving it to the kernel. Instead, each triplet is treated as one object and for every Inode type (file, pipe, socket, etc.) separate image is introduced. Thus CRIU has
 * reg-files.img for regular files, that are created by open() call
@@ Line 48: / Line 48: @@
 * etc.
-In each of this files info about File and Inode of respective file is preserved. Dentry information is effectively stored there for regular files only -- the file's ''path''.
+A full list of image files generated by CRIU is available in [[Images]].
 == How CRIU gets the information to dump ==

← Older revision		Revision as of 12:55, 13 July 2017
Line 87:		Line 87:
	[[Category:Under the hood]]		[[Category:Under the hood]]
	[[Category:Files]]		[[Category:Files]]
		+	[[Category:Editor help needed]]

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

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

← Older revision		Revision as of 18:05, 3 December 2014
Line 22:		Line 22:

	The File object can be referenced by more than on FDT, e.g. when a task calls <code>fork()</code> the child one gets new FDT, but it references the same Files as the parent does, i.e. Files become shared objects.		The File object can be referenced by more than on FDT, e.g. when a task calls <code>fork()</code> the child one gets new FDT, but it references the same Files as the parent does, i.e. Files become shared objects.
		+
		+	[[File:Dumping_files-002.svg\|thumb\|upright=3\|center]]

	The Inode object is also interesting. First of all, remember that in Linux file descriptors can be obtained not only by the <code>open()</code> system call, but also by <code>pipe()</code> and <code>socket()</code> and a bunch of Linux-specific <code>epoll_create</code>, <code>signalfd</code> and others. So when serving ''this'' Linux would anyway create the mentioned above chain of File-Dentry-Inode objects, but the Inode one will be different for different calls. And CRIU knows this all and acts respectively :)		The Inode object is also interesting. First of all, remember that in Linux file descriptors can be obtained not only by the <code>open()</code> system call, but also by <code>pipe()</code> and <code>socket()</code> and a bunch of Linux-specific <code>epoll_create</code>, <code>signalfd</code> and others. So when serving ''this'' Linux would anyway create the mentioned above chain of File-Dentry-Inode objects, but the Inode one will be different for different calls. And CRIU knows this all and acts respectively :)

@@ Line 19: / Line 19: @@
 So after <code>open()</code> (or some other, see below) system call there will be this chain in the memory
-[[File:Dumping_files-001.svg|thumb|center]]
+[[File:Dumping_files-001.svg|thumb|upright=2|center]]
 The File object can be referenced by more than on FDT, e.g. when a task calls <code>fork()</code> the child one gets new FDT, but it references the same Files as the parent does, i.e. Files become shared objects.

@@ Line 92: / Line 92: @@
 Getting the Inode state is specific to Inode. CRIU uses the following sources of information:
-# Date from ''/proc/$pid/fdinfo/$fd/''
+# Data from ''/proc/$pid/fdinfo/$fd/''
 # Link target of ''/proc/$pid/fd/$fd/'' link
 # Inode-specific ioctl()-s
-# read/recv/tee-s to fetch data from descriptor (pipe data, socket queues)
+# Fetch data directly from FD with recv + MSG_PEEK for socket queues and tee for pipes/fifos
-# sock_diag info to get info about sockets
+# Info from sock_diag modules to get info about sockets
 [[Category:Under the hood]]

@@ Line 78: / Line 78: @@
 === Files sharing ===
-In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU [[uses|Kcmp trees]] the <code>kcmp</code> system call.
+In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU [[Kcmp trees|uses]] the <code>kcmp</code> system call.
 === Determining Inode type ===

← Older revision		Revision as of 11:51, 1 December 2014
Line 64:		Line 64:

	== How CRIU gets the information to dump ==		== How CRIU gets the information to dump ==
		+
		+	So on dump CRIU needs to find out several things.
		+
		+	# The FD numbers owned by tasks
		+	# How File-s are shared between tasks' FDTs
		+	# What Inode types are there
		+	# State of File and Inode objects
		+
		+	=== FD numbers ===
		+
		+	This is simple. Reading the ''/proc/$pid/fd'' or ''/proc/$pid/fdinfo'' directory just shows the required numbers.
		+
		+	=== Files sharing ===
		+
		+	In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU uses the <code>kcmp</code> system call.
		+
		+	=== Determining Inode type ===
		+
		+	The inode type in most of the cases can be found out by <code>stat()</code>-ing the descriptor. To do this CRIU asks the [[parasite code]] to send back the files via unix socket's <code>SCM_RIGHTS</code> message. After this, having the same Files at hands CRIU <code>fstat</code>s each and checks the <code>st_mode</code> field.
		+
		+	For some stupid files (signalfd, inotify, etc.) the mode field is zero and CRIU reads the ''/proc/$pid/fd/$fd/'' link. For those the link target uniquely defines the Inode type.
		+
		+	=== State of File and Inode ===
		+
		+	From File CRIU needs only two things -- the mode and the position. Both can be read from ''/proc/$pid/fdinfo/$fd/'' and the latter one can be requested via <code>lseek</code> call.
		+
		+	Getting the Inode state is specific to Inode. CRIU uses the following sources of information:
		+
		+	# Date from ''/proc/$pid/fdinfo/$fd/''
		+	# Link target of ''/proc/$pid/fd/$fd/'' link
		+	# Inode-specific ioctl()-s
		+	# read/recv/tee-s to fetch data from descriptor (pipe data, socket queues)
		+	# sock_diag info to get info about sockets
		+
		+	[[Category:Under the hood]]