[OpenAFS-devel] Re: [OpenAFS release-team] volume time stamp analysis

[Benjamin Kaduk]

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 <jaltman@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