Okay, first the basics: cls_rbd.cc operates only on rbd header objects, so it's doing coordinating activities, not the actual data handling. When somebody does an operation on an rbd image, they put some data in the header object so that everybody else can coordinate (if it's open) or continue (if they're opening it later). A "snap" is a snapshot of the RBD image, which does exactly what snapshots always do (from a user perspective): you can use the snapshot name/ID to refer to the exact data that's on-disk now. Writes that happen after a snapshot are COWed, so you only store deltas, not a full copy of the image. Snapshots in RADOS are not themselves writeable. A "clone" is designed a bit differently: it lets you create a new, *writeable* image which maps back to the base image for any unwritten extents. Unlike a snapshot, you can write to the clone and it diverges from any other clones or snapshots which are taken on the base image. So yes, neither one does any real data write in cls_rbd, because they're just updating pointers used by the clients so that the data is arranged properly when the clients access the rbd image. However, a snapshot is a property of the image, and its data lives next to the rest of the images data; the clones are creating new images which live somewhere else. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com On Tue, Jul 15, 2014 at 9:14 AM, fastsync <fastsync at 163.com> wrote: > hi,all > i take a glance at ceph code of cls_rbd.cc. > it seems that snap and clone both do not R/W any data, they just add some > keys and values, even rbds in different pools. > am i missing something? or could you explain deeper about the implemention > of snap and clone. > > > thanks very much. > > > > > > _______________________________________________ > ceph-users mailing list > ceph-users at lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >
 |