Thanks for the feedback, Maged. On Fri, 04 May 2018 20:09:44 +0200, Maged Mokhtar wrote: > On 2018-05-02 00:36, David Disseldorp wrote: ... > > The Ceph (v13.0.2-1974) OSD request expiry functionality is added via a > > new (likely in the completely wrong place) class="user" fn="expire_req" > > call: > > https://github.com/ddiss/ceph/commits/poc_osd_req_expiry > > > > This new class function is then invoked via an op that is prefixed to > > all kRBD OSD write requests *if* the image is mapped with a > > write_expiry_msec=X parameter: > > https://git.samba.org/?p=ddiss/linux.git;a=shortlog;h=refs/heads/poc_krbd_wreq_expiry ... > For cloned images: in rbd_obj_read_from_parent() you just get the > current time now but in rbd_obj_issue_copyup() we use original request > time, this is ok since the first is a read op ? I've only focused on write-type operations for now. I think it'd actually make sense to also offer a read_expiry_msec parameter, so that all requests can optionally carry an expiration time. > Is there any performance impact from calling current_kernel_time64() > since it does use locking, can we use __current_kernel_time() or even > something less accurate we derive from jiffies since we do not need that > much accuracy. I haven't done any performance tests on the PoC yet, but yes, a low resolution clock would probably be preferable here. > just a cosmetic thing, would it be better to have 2 versions: > rbd_img_request_create and rbd_img_request_create_ex and have the later > take the timespec64 parameter ? That might be a little cleaner, I'll take a look. > i would also be interested to look at the patches to target_core_rbd, > were these done against the 4.17 kernel or the SUSE SLE 12 SP3 branch ? Okay, I'll send them through. I did them against the SLE12SP3 branch. > Do you initialize the started time just before calling > rbd_img_request_create() ? In LIO I added se_cmd init time tracking to transport_init_se_cmd(). > what i hope to do is initialize this time > from the time stamps of received packets, which seems to be > straightforward from your current patches. I like that approach, but am still a little concerned about the complexity it potentially adds to LIO and the librbd API (adding a timeout parameter for every request). > Really nice work, i am really eager to build this. Thanks :) Cheers, David -- 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
