On 25 Jun 2013, at 00:57, Benjamin Kaduk wrote: > So, we would introduce a flags framework with a DBVERSION bump, and then > allocate flags for new features?
This really does feel like it is unnecessary complexity for now. Until lots of people start proposing database format changes, a single monotonic version number should serve OpenAFS fine. > I guess we could steal a couple of words in the header to indicate > (respectively) "feature supported/enabled by the running quorum" and "feature > in use in this database". The problem is that you don't know the feature set supported by the running quorum. Only the master can write to the database - so even if that updates the database with its feature set every time it is restarted, the slaves get no say. One of the challenges with Ubik is that there is currently no mechanism to do configuration negotiation during a quorum election. So there's no way to notice during that election that a slave's configuration is non-standard. This problem also arises when discussing what to do with backwards compatibility. Even if it is possible to allow "old" servers to continue to read, but not write to, the database, it is only safe if they provide exactly the same results as "new" servers. For example, running a cell with a mixture of servers with and without supergroups isn't safe even in read only mode, because the results of pt_GetCPS will differ dramatically depending upon which database server the file server is talking to. > I am deliberately not making a concrete proposal for how to handle the > supergroups transition right now; There isn't a "supergroups transition". The current supergroups implementation is an unavoidable fact of our current database version - we have to assume that all of the supergroups fields are occupied in all databases with that version, and our recovery tools have to deal with the imperfections of the way supergroups are currently stored. I think all of this only really comes into play when we're discussing how to store GSS names within the database. And it seems to me that the simplest way of doing that is with a controlled version number bump. Cheers, Simon _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
