List of filesystems to use generic checkpoint fops

List of filesystems to use generic checkpoint fops

[Matt Helsley]

In case anyone's curious here is my list of filesystems which I think should
have generic_file_checkpoint fops (31):
	adfs
	affs
	befs
	bfs
	btrfs
	cramfs
	ecryptfs
	efs
	fat
	freevxfs
	hfs
	hfsplus
	hpfs
	hppfs
	isofs
	jffs2
	jfs
	minix
	ntfs
	omfs
	openpromfs
	qnx4
	ramfs
	reiserfs
	romfs
	squashfs
	sysv
	ubifs
	udf
	ufs
	xfs

I also added the checkpoint operation to generic_ro_fops since it's used
only in the set of filesystems listed above. For the curious:
	befs
	cramfs
	efs
	freevxfs
	isofs
	romfs
	squashfs

I've got the patches split out per-filesystem even though they are
incredibly tiny. I'll keep rebasing them on the latest git trees from Dave's
kernel.org tree until the checkpoint fop set is ready to be sent to Oren.

The net result is I haven't added any checkpoint operations to filesystems
outside the lists above.

Open ramfs directories aren't checkpointable because, like many special
filesystems, the directories are kept in the dcache with
simple_dir_operations from libfs.c. Filesystems that use it include:
	autofs
	cifs
	debugfs
	devpts
	fuse
	hugetlbfs
	ocfs2
	ramfs

I think I could fix this with a private copy of simple_dir_operations but I
wasn't certain it would work or that it was the best way to handle it. So I've
postponed full ramfs checkpoint support. This means that ramfs files are always
checkpointable but the directories aren't.

A few "regular" filesystems have /proc or debugfs contents (many of them
using the seq_file API). These tend to contain information about the
filesystem or special control interfaces (btrfs). I'm not quite sure
what we'll want to do with these for now. I think eventually we'd add a
checkpoint operation to the seq_file API. My hunch is the majority
of seq_files won't be checkpointable. I also suspect that the
control files won't usually care what the file position is so we may be
able to add generic_file_checkpoint to those after a more careful review of
each one.

It may be easier to remember what's left "TODO" in fs/*:
	9p
	afs
	autofs[4]
	cifs
	coda
	configfs
	debugfs
	devpts
	ext[234] (Dave's handling this)
	(anything that uses dlm)
	fuse
	gfs2
	hostfs
	hugetlbfs
	(anything that uses jbd[2])
	ncpfs
	nfs (I've got patches for NFS but I don't trust them yet and they lack
		support for the seq_file interfaces in /proc)
	ocfs2
	proc (HUGE)
	ramfs
	smbfs (deprecated, so .. never?)
	sysfs

	bad_inode.c (unused outside bad_inode.c so low priority??)
	binfmt_misc.c
	block_dev.c
	char_dev.c (def_chr_fops)
	epoll (eventpoll.c)
	eventfd.c
	fifo.c
	filesystems.c (/proc/filesystems)
	no-block.c
	notify/*
	select.c
	signalfd.c
	locks.c
	pipe.c

I haven't looked outside of fs/* for anything that uses struct file_operations 
-- I'm assuming most of that is for "irregular" filesystems :).

Cheers,
	-Matt

Re: List of filesystems to use generic checkpoint fops

[Oren Laadan]

Matt Helsley wrote:
> In case anyone's curious here is my list of filesystems which I think should
> have generic_file_checkpoint fops (31):

Thanks, Matt.

> 	adfs
> 	affs
> 	befs
> 	bfs
> 	btrfs
> 	cramfs
> 	ecryptfs
> 	efs
> 	fat
> 	freevxfs
> 	hfs
> 	hfsplus
> 	hpfs
> 	hppfs
> 	isofs
> 	jffs2
> 	jfs
> 	minix
> 	ntfs
> 	omfs
> 	openpromfs
> 	qnx4
> 	ramfs

I'd think that in the case of ramfs we always need to dump the contents of the
file, or the entire file system, with the checkpoint image.

> 	reiserfs
> 	romfs
> 	squashfs
> 	sysv
> 	ubifs
> 	udf
> 	ufs
> 	xfs
> 
> I also added the checkpoint operation to generic_ro_fops since it's used
> only in the set of filesystems listed above. For the curious:
> 	befs
> 	cramfs
> 	efs
> 	freevxfs
> 	isofs
> 	romfs
> 	squashfs

??

[...]

Oren.

Re: List of filesystems to use generic checkpoint fops

[Dave Hansen]

On Fri, 2009-03-27 at 10:56 -0400, Oren Laadan wrote:
> 
> >       ramfs
> 
> I'd think that in the case of ramfs we always need to dump the
> contents of the
> file, or the entire file system, with the checkpoint image.

It's really no different than a disk-based one.  We're requiring
somebody to move all the data around between our checkpoint/restart
operation.  If there's data on ramfs that the container needs, then it
needs to get moved just like anything else.  In the OpenVZ case, they
just rsync it.

-- Dave

Re: List of filesystems to use generic checkpoint fops

[Matt Helsley]

On Fri, Mar 27, 2009 at 10:56:51AM -0400, Oren Laadan wrote:
> 
> 
> Matt Helsley wrote:
> > In case anyone's curious here is my list of filesystems which I think should
> > have generic_file_checkpoint fops (31):
> 
> Thanks, Matt.

You're welcome!

<snip>
> > 	ramfs
> 
> I'd think that in the case of ramfs we always need to dump the contents of the
> file, or the entire file system, with the checkpoint image.

I anticipated Dave's answer when I lumped ramfs with "regular"
filesystems. To the best of my knowledge it doesn't matter what kind of "block"
device backs these files. Only that the file contents can be migrated somehow
and that they support the seek operation.

Note that procfs is difficult for checkpoint/restart because the contents
often can't be migrated using rsync. Each non-process /proc file probably
will need its own checkpoint operation. I suspect this would frequently need to
be passed through an extended seq_file API much like the checkpoint op
extends the VFS file_operations. 

> > 	reiserfs
> > 	romfs
> > 	squashfs
> > 	sysv
> > 	ubifs
> > 	udf
> > 	ufs
> > 	xfs
> > 
> > I also added the checkpoint operation to generic_ro_fops since it's used
> > only in the set of filesystems listed above. For the curious:
> > 	befs
> > 	cramfs
> > 	efs
> > 	freevxfs
> > 	isofs
> > 	romfs
> > 	squashfs

The patch modifying generic_ro_fops doesn't quite match the pattern
established when patching the other filesystems so I thought it deserved
special mention. The other filesystems all define their own file_operation
structs but these share one.

Amongst other things these filesystems do not allow modifications to their file
contents. Consequently they share generic_ro_fops rather than define their own
file operations. cramfs, isofs, romfs, and squashfs are designed to be static,
offline-generated filesystems so generic_ro_fops makes sense here. I guess befs,
freevxfs, and efs are legacy filesystems and there is little reason to
implement write operations for them.

Cheers,
	-Matt