Assuming the RBD object-map feature is *not* enabled, if the associated backing object was not overwritten in rbd2 nor rbd3, every read operation to that object would involve first attempting to read from rbd3's object, then rbd2's, followed by rbd1's, which would introduce extra latency. The first write against a clone will also introduce extra latency since the whole backing object needs to be read from the parent and re-written to the clone. If the object map is enabled, the client would have an in-memory map for all images in the hierarchy so it can skip unnecessary read requests to the parent (and associated latency) if it knows the parent doesn't have the requested backing object. The first write against a clone would, in addition to the CoW overhead, also have to update the image object map on-disk to indicate the clone now contains the affected block. On Wed, Jun 7, 2017 at 4:50 AM, xiaoyang.yu@xxxxxxxxxxxxx <xiaoyang.yu@xxxxxxxxxxxxx> wrote: > Hi all: > after clone from base image snapshot,we get a new rbd named "rbd1", now we > can snapshot rbd1, then clone from "rbd1" we get a new "rbd2", clone from > "rbd2" we get "rbd3"... > would rbd cascade clone affect performance? > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Jason _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |