[OpenAFS] vos release not as "smart" as I thought - or is this a not implemented feature?

[Harald Barth]

> https://lists.openafs.org/pipermail/openafs-info/2019-September/042865.html

Hi Ben!

I read it previously but did probably not understand. Does this mean that it always 
pulls everything from "last update" minus 15 minutes even if the last pull was
long _after_ the creation date of the readonly? Does that make sense?

Here I have:

RO dates
    Creation    Mon Nov 25 14:11:46 2019
    Copy        Mon Nov 25 10:51:37 2019
    Backup      Mon Nov 25 01:17:02 2019
    Last Access Mon Nov 25 10:57:40 2019
    Last Update Mon Nov 25 10:57:40 2019
 
RW last update:
    Last Update Mon Nov 25 10:57:40 2019

But the logic does not seem to look at the RO creation
time? 


$ vos rele H.haba.android  -verbose -c stacken.kth.se

H.haba.android 
    RWrite: 536916074     ROnly: 536916075     Backup: 536916076 
    number of sites -> 3
       server bananshake.stacken.kth.se partition /vicepb RW Site 
       server bananshake.stacken.kth.se partition /vicepb RO Site 
       server vaniljshake.stacken.kth.se partition /vicepb RO Site 
This is a complete release of volume 536916074
Re-cloning permanent RO volume 536916075 ... done
Getting status of parent volume 536916074... done
Starting transaction on RO clone volume 536916075... done
Setting volume flags for volume 536916075... done
Ending transaction on volume 536916075... done
Replacing VLDB entry for H.haba.android... done
Starting transaction on cloned volume 536916075... done
Updating existing ro volume 536916075 on vaniljshake.stacken.kth.se ...
Starting ForwardMulti from 536916075 to 536916075 on vaniljshake.stacken.kth.se (as of Mon Nov 25 10:57:38 2019).
updating VLDB ... done
Released volume H.haba.android successfully

And after we got a new creation date yet more in the future (compared
to the Last Update date):

H.haba.android.readonly           536916075 RO    3062302 K  On-line
    vaniljshake.stacken.kth.se /vicepb 
    RWrite  536916074 ROnly          0 Backup          0 
    MaxQuota   50000000 K 
    Creation    Thu Nov 28 09:56:40 2019
    Copy        Mon Nov 25 10:51:37 2019
    Backup      Thu Nov 28 01:17:02 2019
    Last Access Mon Nov 25 10:57:40 2019
    Last Update Mon Nov 25 10:57:40 2019

Does that mean I should look at the horriffic source code of vos
again?

Cheers,
Harald.

PS: 

Jeff> The behavior you are expecting is implemented
Jeff> by AuriStorFS vos

And for various "reasons" (Beer often helps to understand these kind
of reasons) PDC/KTH could not be convinced to shop that (yet?). But
that would not have helped for the Stacken cell anyway.