Andrew, I agree that whole DB operations such as backup and restore could and probably should exist in an independent rx service because of the transactional nature of manipulating the entire db.
At the most recent Pittsburgh hackathon there was an effort to extend the ubik db to use more than one db file. This effort failed because it is not possible using the existing DISK operations to perform transactions on more than one db file at a time. Extending the db to use multiple files is desirable for the implementation of the PTS Extended Names extensions draft-brashear-afs3-pts-extended-names One downside of relying upon the existing DISK RPCs for reading the db is that such an approach is limited to a single file. Any new rx service that permits backup and restore of the live DB should support doing so for multiple file DBs as a single transaction even though they do not exist today. Jeffrey Altman On 11/14/2013 3:08 PM, Andrew Deason wrote: > I just submitted a gerrit change to introduce a new ubik RPC: > <http://gerrit.openafs.org/10461>. The DISK_ service is possibly not the > best place to introduce such an RPC, but it doesn't look like there's an > existing place for it that makes much sense to me. So I thought I'd open > up some discussion about this kind of thing to the list. My > understanding is that this is not a conversation appropriate for > afs3-stds, since this deals with RPCs and such internal to OpenAFS, and > we don't guarantee interop since we're not dealing with clients. > > Some background: the motivation for this and the current proposed > ubik_cp tool functionality is the ability to 'read' and 'write' a full > ubik database without needing to stop/shutdown dbservers or worry about > consistency, etc, etc. So we can 'read' a database while the server is > online, and we can perform some analysis on it or transmit it to another > cell or whatever. And, with something like gerrit 10461, we can > 'restore' a database if we want to copy a database into the running > machine. > > Gerrit 9700 achieved the 'read' functionality by sort-of hijacking an > existing ubik RPC that's used for sending the database data in bulk to > sites that don't have the database. That may not be great way to do it > long-term, but it does work for existing sites with unmodified > dbserveres, which is why it was useful. > > There is no way to (for the general case) do the same thing for a > 'write' operation, which is why gerrit 10461 exists. However, the new > DISK_RestoreDB RPC is quite different from all of the other DISK_ RPCs > that exist right now. The other DISK_ procs are intended to be used in > an automated way between dbservers to handle transaction and database > modifications inside a transaction, etc. DISK_RestoreDB (as it exists in > gerrit) instead operates at a higher level, creating a transaction > itself, and it's not meant for the other dbserver sites to be running it > as part of normal operation. Instead, it's to be run by an administrator > or by some automated process outside of ubik. > > So, to me this sounds like a new service; it's not similar to anything > in VOTE_ or DISK_ (except maybe the debug RPCs), but it needs to run in > the ubik layer, not e.g. the vlserver or ptserver layer, since it > applies to anything using a ubik db. The RPCs in this service would > allow you to consistently read the db, restore the db, maybe enter and > exit a kind of 'read-only' mode... stuff like that. > > If such a new service existed, we could then maybe have a new command > suite called 'ubik' (or ubikctl, ubikcmd, etc) that generally calls the > RPCs in that service. I would then use that command for the > functionality I'm currently including in ubik_cp, and drop ubik_cp. > > Any thoughts? >
smime.p7s
Description: S/MIME Cryptographic Signature
