Just to be clear, why do we think it doesn't serve as an optimization? In IRC discussion, it's been stated that the implementation doesn't scale properly with multiple rgw instances doing sync--that it will begin to lose hints altogether when its (round-robin) selection of a destination endpoint reaches an rgw that cannot handle the given shard). OTOH, as Yehuda points out, the intended purpose of the async notifies was to implement polling avoidance--to provide wake-ups to sync endpoints that might otherwise sleep/idle as replication events accumulate. This is a well established design pattern, and if we remember that the async notifies are duplicating hints, it seems to make sense. The fact that the hint accuracy badly degrades with multiple rgws is a problem. The complexity of implementation is a very different objection. Is it logically necessary to be complex, or is that an artifact of the implementation? Casey also suggests it competes with replication bw, or latency. Maybe we should measure that. On Tue, Mar 22, 2022 at 1:52 PM Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: > > 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 > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
