[Devel] Re: [C/R v20][PATCH 38/96] c/r: dump open file descriptors

[Andreas Dilger]

On 2010-03-18, at 18:59, Oren Laadan wrote:
> +int checkpoint_fname(struct ckpt_ctx *ctx, struct path *path,  
> struct path *root)
> +{
> +	fname = ckpt_fill_fname(path, root, buf, &flen);
> +	if (!IS_ERR(fname)) {
> +		ret = ckpt_write_obj_type(ctx, fname, flen,
> +					  CKPT_HDR_FILE_NAME);

What is the intended use case for the checkpoint/restore being  
developed here?  It seems like a major risk to do the checkpoint using  
the filename, since this is not guaranteed to stay constant and the  
restore may give you a different state than what was running when the  
checkpoint was done.  Storing a file handle in the checkpoint, instead  
of (or in addition to) the filename would allow restoring the state  
correctly.

Note that you would also need to store some kind of FSID as part of  
the file handle, which is a functionality that would be desirable for  
Aneesh's recent open_by_handle() patches as well, so getting this  
right once would be of use to both projects.

That said, if the intent is to allow the restore to be done on another  
node with a "similar" filesystem (e.g. created by rsync/node image),  
instead of having a coherent distributed filesystem on all of the  
nodes then the filename makes sense.

I would recommend to store both the file handle+FSID and the filename,  
preferring the former for "100% correct" restores on the same node,  
and the latter for being able to restore on a similar node (e.g.  
system files and such that are expected to be the same on all nodes,  
but do not necessarily have the same inode number).

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers