On Fri, 21 Jun 2013, Simon Wilkinson wrote:
On 10 Jun 2013, at 17:24, Benjamin Kaduk wrote:
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.
At the moment, OpenAFS doesn't support running mixed dbserver
environments. This is a hangover from the IBM days, but pretty much all
of our documentation is clear that a dbserver upgrade requires a
Sure, and that's why I'm still running 1.4 dbservers on my new wheezy
machine while I upgrade the rest of the cell.
But, we've never really broken the database format between versions, and
I'm pretty sure that some people on the lists have reported running mixed
1.4 and 1.6. So I don't really think we can claim that no one actually
does run a mixed environment.
complete shutdown, upgrade, restart process. I don't think a UUID helps
in enough of the edge cases to be worthwhile having.
Yeah, I'm not really convinced there's a need for a UUID.
There are two things I think we should have to make this easier.
Firstly, we should actually use the version number, and increase it each
time there is a change made to a ubik database that isn't backwards
compatible. Secondly, we should make sure that we don't end up with n^2
That would seem to be the whole point of a version field, yes. But where
does one draw the line on "backwards compatible"? Is it "any new
feature", or are there edge cases where old servers could still do
basically sane things when presented with new data?
In particular, I am assuming that you are claiming that the current
proposal for extended hash tables and data blocks to store extended names
should get a version bump; please confirm.
possible db formats. That means that we should never make the ubik
database format dependent upon configure flags. That probably means that
we should just turn on supergroups for everyone.
I think the follow-ups have made this point more subtle; I'll reply to one
of those.
-Ben
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
