Hi The parent image of "clone-vol1", which is "ori-vol1", is not touched during the test. Regards Ridge 2016-08-16 10:22 GMT+08:00 Jason Dillaman <jdillama@xxxxxxxxxx>: > 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
