Adding back openafs-devel for the volume time stamp analysis. The email threading has not really been preserved, but hopefully we can figure things out.
On Wed, 10 Dec 2014, Jeffrey Hutzelman wrote: > On December 10, 2014 12:00:42 AM EST, Jeffrey Altman <jalt...@openafs.org> > wrote: > >On 12/9/2014 12:36 PM, Benjamin Kaduk wrote: > > > >> On the volume header times, jhutz thinks 11468 should go in, but > >points > >> out that there are further improvements possible. Are we okay with > >> (potentially) deferring those until after 1.8 branches, treating them > >as > >> bugfixes? > > > >There are two outstanding issues. > > > >1. There is the possibility that V_backupDate(vp) might not be set due > >to an error. This is easy to handle and we should do so. I pushed gerrit 11627 on top of gerrit 11468 to handle the case where backupDate is zero, as was suggested previously. > >2. There is a secondary problem related to V_updateDate(vp) only > >tracking changes to vnodes and not other volume data that is > >represented > >in the dump stream. My opinion is that all data and metadata > >represented in the dump stream should tracked. Otherwise, it is > >possible to miss that non-vnode data had changed and therefore no > >backup > >would be performed. However, this is a significant change and I do not > >believe there is consensus to make such a change. > > I agree on 1, and that there is not yet a consensus on 2. Really, I I think I agree that there is not yet consensus on 2; I would like to propose that we do not need to come to an agreement on 2 before the 1.8 release. > think we need several more dates, but to a certain extent, we need to > give the existing fields semantics that induce the correct behavior in > existing tools. IMHO any change we make to updateDate has to be > something we agree is sufficiently backward compatible, regardless of > when it goes in. I think that means we don't necessarily have to hold > 1.8 for such a change, and in fact it could go in 1.6. Once we agree > the change is appropriate. We must assume that cells will be operating with lots of different versions of clients running around, so I don't see how this could not be the case. > There is also the additional issue that restored volumes may have > incorrect dates, depending on what version did the restore. we should > clean this up and, ideally, account for it somehow when selecting dump > dates, but those are incremental improvements that can be done as > additional changes. Sure. So, my understanding of things is that 11468 and probably 11627 should go in to master/1.8, and there are other incremental improvements that could be made but are not release blockers. Possibly a comment should change in 11468 before it goes in. Does that seem like a correct summary? -Ben _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
