[OpenAFS-devel] prdb format extension for extended authentication names

Jeffrey Hutzelman jhutz@cmu.edu
Fri, 28 Jun 2013 17:18:54 -0400


On Fri, 2013-06-28 at 17:08 -0400, Benjamin Kaduk wrote:

> > - The database format changes linearly for now.  To use a new feature,
> > you must
> >  have a database version which is new enough to support that feature.
> > - Database version bumps are explicit, and are managed via a set of RPCs
> > that
> >  allow getting the current and maximum supported version and upgrading
> > to a
> >  version not newer than the maximum.
> 
> Agreed.  Can I make you propose RPC names so I don't have to? :)

PR_GetDatabaseVersions(OUT afs_uint32 *current, OUT afs_uint32 *max);
PR_UpgradeDatabaseVersion(IN afs_uint32 newvers);


> > - Checking version support before upgrading is handled by the pts
> > command that
> >  does the upgrade, and a -force flag is provided.
> 
> I would have thought that the ptserver would have a better sense of what 
> machines are in the ubik quorum than the client running pts, but my 
> understanding of how ubik works is spotty.  If you think this is fine, I'm 
> happy to go with it.

Oh, it probably does.  I'm happy with doing it either way.  If you want
the server to do the checks, then the upgrade RPC needs a force
parameter.


> >  I imagine that on the wire, a knob has a 32-bit name and a 32-bit
> > value.  Of
> 
> Would the "name" be an enumeration value, or something like a bitmask 
> for the on-disk format?  I guess an enumeration value makes more sense, if 
> the reserved on-disk space to hold these things grows larger than a word. 
> The values would still all be expected to be representable in a bit or 
> two, though.  (Unless we want to get fancy and reserve space outside of 
> the header?)

It's an enumeration value.  The on-the-wire representation is an
abstraction.  The names don't appear at all on disk, and the values
appear wherever is appropriate, depending on what they are.


> I'm not sure where the on-disk space for all of those would come from, but 
> in principle it could be done.

Whoever wants to add those features will have to find a place for them.
That could mean allocating some blocks to extend the header.


-- Jeff