On the RBD side of the house, since RBD won't be (purposely) delaying notification ACKs, about the only thing it can do is just log that it must have a laggy connection. It might be useful for diagnostics, but I can't think of any immediate use for doing something proactive to correct the delay. -- Jason Dillaman Red Hat dillaman@xxxxxxxxxx http://www.redhat.com ----- Original Message ----- From: "Sage Weil" <sage@xxxxxxxxxxxx> To: ceph-devel@xxxxxxxxxxxxxxx Sent: Monday, November 17, 2014 7:42:14 PM Subject: Re: watch/notify changes ready for review On Thu, 13 Nov 2014, Sage Weil wrote: > My pile of watch/notify changes are ready for review: > > https://github.com/ceph/ceph/pull/2924 Okay, I did another round of cleanup (including moving most of the code into Objecter) and it's now way cleaner and passing all the basic tests (hasn't gone through full yet). I still have a big outstanding question: Does the failed notify API make sense? I'm leaning no, but want another opinion before I go rip it back out. To summarize: it notifies a watcher if it was slow to respond to an earlier notify and caused the notifier to time out. Counterargument: if the notifier wants to tell everyone they saw a timeout, they could send another notify; at least then they would know if the second piece of information was delivered (quickly). I don't think that librbd or rgw will make use of it. The last bit of work remaining is to migrate RGW over to the new API and make it use watch_check(). Will work with Yehuda on that, but in the meantime, this is ready for review! sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
