Discussion in gerrit 1235 has suggested the use of a new field in the disk header of volumes. Namely, a redundant location for the DataVersion of the root vnode in the volume.
The purpose of this is for when we are salvaging a volume that has lost its root vnode. Gerrit 1235 has the code to create a new root vnode, but we must guess as to what the dv for it would be. The current guess is based on the creationDate for the volume, which isn't really robust. So instead, if we store the root dv redundantly in the volume header, we stand a much better chance at choosing a dv that won't screw up clients, since we can base the new dv off of the last known dv. This email is a request for any objections or problems with doing so, and just to let people know. The only possible problem I could see is that using up a field to solve a problem that occurs so rarely (and can sort-of be worked around) may be wasteful, but I don't think we're that cramped for header fields yet. I was thinking to use a 'reserved1' bit32 (or should 2 of them be claimed? will DVs always be 32-bits?), in struct VolumeDiskData. Since the header is already written every 128 accesses for stats and such, I don't anticipate any change to that, so there's no performance difference. Any thoughts? -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
