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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
