The "assert object exists" check is just a "stat" op inserted before the write op in the same transaction. If the object doesn't exist (i.e. a clone copy-on-write is required), the transaction will fail within the OSD and librbd will know it needs to perform a copy-up. However, in your case, this stat op should be essentially a no-op so I would expect zero performance penalty. Do you rebuild your images after every test run? I ask because one big difference is that when you are writing to the parent image, it has a snapshot so the first write to a backing object would require a copy-on-write operation within the OSD. On Mon, Aug 15, 2016 at 10:05 PM, Ridge Chen <ridge.chen@xxxxxxxxx> wrote: > Hi > > Thanks for your quick response. > > Yes, the result is similar with object-map disabled. And in all my > tests the librbd cache is disabled. > > Could you explain more about the additional "assert object exists" > operation? what it does in osd side? > > And can we bypass the operation in this very common case based on the > object-map feature? > > Regards, > Ridge > > 2016-08-15 20:16 GMT+08:00 Jason Dillaman <jdillama@xxxxxxxxxx>: >> On Sun, Aug 14, 2016 at 10:41 PM, Ridge Chen <ridge.chen@xxxxxxxxx> wrote: >>> I have tested on hammer and jewel, the results are similar. Is it expected? >> >> In this case, there actually would not be an extra copy-up since you >> already performed the necessary copy-ups during the "dd" against >> "clone-vol1". The only difference, on the librbd side, is that the >> write operation would have an additional "assert object exists" >> operation before the write operation. >> >> Do you see similar differences with the librbd cache disabled and the >> object map disabled? >> >> >> >> -- >> Jason -- Jason -- 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
