On 8/6/2018 12:12 PM, Ximeng Guan wrote: > Indeed if we have two RO replicas at Site B and RW at site A, subsequent > release will be twice as consuming, unless "vos release" can be made to be > even smarter, such that data is "relayed" among RO sites instead of being > broadcasted from the RW site. > > I guess that touches some fundamental part of "vos release" which is not > trivial: How to optimize the data propagation path for different network > scenarios? How does that affect the integrity among different replicas?
In OpenAFS, all of the "smarts" are in the vos process. This process has no knowledge of the network topology which is why OpenAFS has difficulties in network environments that lack full end-to-end connectivity between all peers. In theory, someone could write a volserver topology map that could be provided to "vos" as input. It could be used in conjunction with the volume site list from the location service to decide how to replicate the volumes. The OpenAFS location service doesn't provide clients (cache managers) any locality information and the Unix cache manager does not rank volume sites based upon performance characteristics. How are you ensuring that clients contact the local fileserver? Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
