[AFS3-std] first draft: ubik update proposal

[Jeffrey Hutzelman]

--On Tuesday, February 15, 2011 02:07:34 PM -0500 Derrick Brashear=20
<shadow@gmail.com> 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=20
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.
>> =C2=A0Previously 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.