> 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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info