On 22/03/2022, Casey Bodley wrote: > a friendly reminder of last year's discussion. i still think we're > better off removing this feature: it's extra complexity in sync code > that's already too complicated, and it doesn't scale to multiple > gateways per zone. the only benefit it provides is in perceived sync > latency, at small scales, when we're mostly caught up already. in most > other cases, it's a detriment to sync performance because of the extra > network traffic, the duplicated processing of most datalog entries, > and loss of temporal locality in the bucket sync cache +1 from me. We don't need the excessive complexity. It isn't required for correctness, and doesn't seem to serve as an optimization. Something vaguely similar (prioritizing buckets, prioritizing new objects over old, etc.) may make sense as an extension of the sync-fairness work, but such a design won't look anything like the current urgent data model and I don't see any benefit to keeping it. _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
