--On Friday, February 04, 2011 09:32:53 AM -0500 Derrick Brashear <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization

Reply via email to