[AFS3-std] first draft: ubik update proposal

[Jeffrey Hutzelman]

--On Friday, February 04, 2011 09:32:53 AM -0500 Derrick Brashear 
<shadow@gmail.com> wrote:

> This is not a complete refresh of all Ubik RPCs. It would allow
> capability for IPv6, 64 bit times, multiple files in a database,
> beacon returns not precluding errors. Comments welcome, I will refine
> further into a draft.

I'm trying to decide whether I think Ubik is even a subject for 
standardization, rather than an implementation detail of OpenAFS.  I don't 
think we necessarily expect ubik servers of different implementations to be 
able to operate together, and certainly database _contents_ are an 
implementation detail.

That said, I'll go ahead and comment on this anyway.


> struct ubik_nversion {
>     afs_int64 epoch;
>     afs_int64 counter;
> };
>
> struct ubik_ntid {
>     afs_int64 epoch;
>     afs_int64 counter;
> };

64-bit epochs are necessary.
64-bit counters seem excessive.

> New package DISK2, would supercede DISK.

Why a new package, instead of just adding RPC's?


> GetFile         (IN afs_int32 file,
> 		IN ubik_nversion *haveVersion,
> 		OUT ubik_nversion *gotVersion)

What's the haveVersion argument for here?


> SendFileDiff    (IN afs_int32 file,
>                 afs_int64 length,
> 		ubik_nversion *fromVersion,
>                 ubik_nversion *toVersion)

What does the length mean here?  The size of the diff?



> when using sendfile or getfile, all files need to be gotten (to the
> same version) before any are moved into place. snapversion should do a
> copy-on-write snapshot of the current files; dropsnap will drop them
> when done. the *filediff can use the snapshot plus locks to do an
> incremental "finish" after transferring all files, in much the same
> way as a volume release is performed.


I'm not clear on how snapshotting interacts with GetFile/SendFile and 
active operations.  I think in practice the mechanism you need is one that 
allows you to "freeze" the target's databases so that active transactions 
read from the frozen copy, while sendfile prepares a "new" copy; note that 
there can be no write transactions, since writes happen only on the sync 
site and these calls are made only by the sync site and never to itself. 
Having done a snapshot and sent some new files, it must be possible to 
either commit the new files or discard them; recovery should only do the 
commit operation if it is still sync site.

-- Jeff