2018-04-13 0:01 GMT+08:00 Ilya Dryomov <idryomov@xxxxxxxxx>: > On Thu, Apr 12, 2018 at 2:58 PM, Jason Dillaman <jdillama@xxxxxxxxxx> wrote: >> On Thu, Apr 12, 2018 at 4:23 AM, handong He <hedongho@xxxxxxxxx> wrote: >>> Hi, cephers: >>> >>> I did some test about rbd cli operation and have some doubt. >>> >>> 1. rbd can be removed during copy operation. And both 'cp' and >>> 'rm' command return success. However the dest-image data is diff from >>> the src-image. >>> why not set a watcher for the rbd_header obj for the opening >>> image. So it will occur error and return image ebusy when run 'rm'. >>> >>> easy to reproduce: >>> 1. rbd cp rbd/img0 rbd/img1 >>> 2. while cp is runing, exec: rbd rm rbd/img0 >>> 3. after finish, just compare two img's du(USED): rbd du rbd/img1 >> >> The rationale is that reading from an image should only require >> read-access to the pool. Establishing a watch on an image requires >> write access. Oh, I see. So It is not properly for user who only has read permission. >> You could also hit a similar problem if you deleted an >> image while exporting it, or deleting a snapshot while reading from >> it, or overwrite an image while copying it, etc, etc, etc. I'd be >> interesting in your use-case where you are realistically hitting these >> scenarios. we use openstack + ceph. In openstack src code, creating a vm will trigger 'clone' from glance image to cinder disk. But we prefer 'copy' instead of 'clone' even though creating vms will be slower. It make us easier to manager the lifecycle of glance images and vms. while someone is creating vms, the other may delete the glance image at the same time. The other case is that when we set 'rbd_max_clone_path = 0' in cinder config, cinder 'create-from-volume' op will use 'rbd copy' instead of 'clone'. For 'copy' may take some time，we can not prevent users doing some weird operations like deleting the cloud disk unless we make some constraints. So it maybe perfect if 'rbd rm' will return error if it is still runing some time-consuming operation like copy, etc. Or we have to make some constraints in the upstream. >>> 2. in krbd, image-feature should be only set 'layering' for the >>> 'map' operation.But for clone image: the child img set layering, but >>> parent img has more feature that krbd not support. it will fail while >>> child img exec ' rbd map'. >>> i think it is logical, but maybe a little complex while the >>> chain is long. we have to lookup every ancestors and make sure their >>> feature is match krbd's support features. will that be any optimize? >>> >>> easy to reproduce: >>> 1. rbd clone rbd/img0@sn1 rbd/img1 --image-feature=layering >>> 2. parent img0 has default feature, which make 'rbd map >>> rbd/img1' failed. >> >> This could probably be improved by having krbd pass the optional >> read-only flag down to the 'get_features' rbd class method [1][2]. For >> the parent image case, it would be opened read-only which means that >> its feature flags would be ANDed with a mask to reduce the >> incompatible feature set [3]. >> >> [1] https://github.com/torvalds/linux/blob/master/drivers/block/rbd.c#L4471 >> [2] https://github.com/ceph/ceph/blob/master/src/cls/rbd/cls_rbd.cc#L403 >> [3] https://github.com/ceph/ceph/blob/master/src/include/rbd/features.h#L32 > > Yeah, we don't make any distinction between rw and ro access in krbd. > I have filed http://tracker.ceph.com/issues/23688. That will be great, Thanks. > Thanks, > > Ilya Thanks for the reply. Handong -- 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
