[OpenAFS] vos release not as "smart" as I thought - or is this a
not implemented feature?
Benjamin Kaduk
kaduk@mit.edu
Wed, 27 Nov 2019 17:42:23 -0800
Did you see
https://lists.openafs.org/pipermail/openafs-info/2019-September/042865.html
?
-Ben
On Mon, Nov 25, 2019 at 02:17:29PM +0100, Harald Barth wrote:
>
> I thought that vos release was smart and only did make a clone +
> transfer if the RW had changed compared to the status of the RO
> clone(s).
>
> This seems not to be the case and I get a clone plus transfer
> (incremental, I guess, but nevertheless) even if the RW was quiet
> and untouched for some time.
>
> Example:
>
> root@bananshake:~# vos exa H.haba.android
> H.haba.android 536916074 RW 3062302 K On-line
> bananshake.stacken.kth.se /vicepb
> RWrite 536916074 ROnly 536916075 Backup 0
> MaxQuota 50000000 K
> Creation Mon Apr 1 08:57:31 2019
> Copy Mon Nov 25 10:49:14 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
> 11 accesses in the past day (i.e., vnode references)
>
> RWrite: 536916074 ROnly: 536916075
> 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 volume was last touched 10:57:40 and now it's 14:11:33 and I do two
> vos release:
>
> root@bananshake:~# vos rele H.haba.android -local -verb
>
> H.haba.android
> RWrite: 536916074 ROnly: 536916075
> 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
> root@bananshake:~# vos rele H.haba.android -local -verb
>
> H.haba.android
> RWrite: 536916074 ROnly: 536916075
> 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
> root@bananshake:~#
>
> So why is there any cloning/replicatin taking place at all when it
> could be determined that the RO clones are up to date?
> I think all relevant versions are 1.6.20-2+deb9u2.
>
> Feel free to run vos commands to get further details.
>
> Thanks,
> Harald.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info