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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
