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

[Benjamin Kaduk]

On Thu, 30 May 2013, Benjamin Kaduk wrote:

>
> Within these considerations (and any others that come up in this discussion), 
> I am working on a concrete proposal.  Would people prefer to see this in the 
> form of ptserver.h struct declarations and comments, or an addition to the 
> prdb format writeup I have at 
> https://github.com/kaduk/openafs/blob/prdb/doc/txt/prdb.txt ?

I updated the description of the existing prdb format a bit, and then 
added descriptions of a format with a generic mechanism for additional 
hash tables and additional types of extended data which may be attached to 
an existing entry.  At present I only describe extended names and the hash 
table for them, but other extensions are certainly possible.

The squashed patchset is two commits at 
https://github.com/kaduk/openafs/commits/prdb-squashed -- one for 
describing the existing format, and another to add my proposed updates.

I have left out the idea of a UUID attached to the generic extended data 
for now.  I think that the main benefit from such a concept would be if 
operating in a mixed environment of new and old ptservers, or if it is 
necessary to revert to the old code for some reason.
If an entry has extended data added using the new code, but is deleted 
using the old code, and a new entry is created with the same ID, then
the database will be corrupt, as the extended data for the old entry is 
still present in the database, and a database verification script would 
attach that extended data to the new entry, for which it is not actually 
valid.  A UUID in the extended data would detect this version skew, so 
long as the new entry had valid extended data associated with it (which 
would have a new UUID that did not match the old extended data).  However, 
if there is no extended data associated with the new entry, I don't think 
the UUID would help.  As such, I'm not convinced it adds value in this 
database-consistency purpose.  Maybe there are other reasons to have a 
UUID per entry, for a new way to look up entries, perhaps, but I am not 
coming up with any that are compelling.

If there are compelling reasons to include a UUID with extended data 
blocks, this is pretty easy to do; we just lose some of the space for 
extended data and add another hash table for lookup by UUID.

It would be nice to get some feedback before I start working on the code.
Jenkins' lookup3 hash should be just fine for the extended names, but we 
will need to enforce endianness.

-Ben