--On Tuesday, February 15, 2011 02:07:34 PM -0500 Derrick Brashear
<[email protected]> wrote:
First, properly, "recovering" is something that only the sync site does.
Other sites don't "recover"; they simply do what they're told.
which, for the purpose of this discussion i refer to as "recovering";
the master site says "take this"
if the "this" you are taking is not recovering you, i'm not really
sure what to call it.
I don't know, but "recovery" is a specific subprocess in Ubik, and it runs
only on the sync site. Please don't overload a term of art.
However, I think you will discover you need an operation which throws
away changes since the snapshot, because as soon as you allow not only
for multiple files but also for the sync site to keep taking updates
during sendfile, there is the possibility that the sync site will stop
being sync site, and need to abort any sends it has in progress.
Previously this was not an issue, because even though the SendFile
took time to run, it was an atomic operation with respect to anything
that might modify the database on either side.
at the end which is having its database updated, you mean?
so e.g. an RPC which at the end of sending files to a site, does
either a commit or abort of the data sent for the recovery process.
yes
and assuming this is openafs-specific (which it seems like a
reasonable thing for it to be; it's certainly not client-facing for
any of these changes, and mixing ubik versions would be a mess)
should we move this discussion to openafs-devel?
I was about to suggest the same thing.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
