Serge E. Hallyn wrote:
Quoting Jamie Lokier (jamie@xxxxxxxxxxxxx):
Matt Helsley wrote:
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.
Yes, this is the intent.
I would worry about programs which are using files which have been
deleted, renamed, or (very common) renamed-over by another process
after being opened, as there's a good chance they will successfully
open the wrong file after c/r, and corrupt state from then on.
Userspace is expected to back up and restore the filesystem, for
instance using a btrfs snapshot or a simple rsync or tar.
That does not solve the problem Jamie is talking about.
A rsync or a tar will not see a deleted file and using a btrfs to have
the CR to work with the deleted files is a bit overkill, no ?
I have another question about the deleted files. How is handled the case
when a process has a deleted mapped file but without an associated file
descriptor ?
If we detect anything which really is not supported (for instance
inotify for now) then we fail and leave a log message explaining the
failure.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
