FYI, this sounds like an issue the userspace client (and possibly the actual rbd class?) had as well: it looked at the "HEAD" parent_overlap field even when reading from snapshots. (I don't remember if parent_overlap is the actual parameter name, but you get the idea.) -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com
On Tue, Jul 15, 2014 at 9:01 AM, Ilya Dryomov <[email protected]> wrote: > On Tue, Jul 15, 2014 at 9:44 AM, Lakshminarayana Mavunduri > <[email protected]> wrote: >> Hi, >> >> Following the below set of steps, we are seeing data loss while reading from >> clones. >> >> 1)Create an image with image format 2 (in this case we have made the size to >> be 1024MB). >> rbd create image1 --size 1024 --image-format 2 >> 2)Map the image and write 1024MB worth of data to it. >> 3)Create a snapshot for the image created in step 1) >> rbd snap create image1@snap1 >> 4)Create a clone for the snapshot created in step 3) >> rbd clone image1@snap1 clone1 >> 5)Create a snapshot for the clone created in step 4) >> rbd snap create clone1@snap2 >> 6)Create a clone for the snapshot created in step 5) >> rbd clone clone1@snap2 clone2 >> 7)Shrink the size of the clone created in step 4) (in this case we have made >> it to half of its size) >> rbd resize -s 512 --allow-shrink clone1 >> 8)Map the clone created in step 6) and try reading 1024MB worth of data. >> 9)Our observation is that, only the first 512MB worth data is intact, the >> rest is not copied over. (In fact, it's only the parent overlap worth data >> of clone1 that is always copied over!) >> >> After the above set of steps, the parent overlap for clone2 would be 1024MB, >> whereas the parent overlap for clone1 would be 512MB. Our understanding is, >> since clone2's parent snapshot is taken before a shrink is performed on >> clone1, any reads worth parent overlap data on clone2 should be serviced >> from it's parent (at least, as long as there are no overwrites done on >> clone2, which is the case here), and we are not finding that to be true in >> this case. >> >> To augment our theory, if the parent image (a base RBD image, which is not a >> clone) is shrinked, any reads on the clones that are created before the >> shrink, are as expected to our understanding. >> >> Wanted to check if this is indeed a bug or if we are missing anything here. >> The tests are run across ceph version 0.80. > > From a quick read, this looks like a bug in the kernel client. I'll > investigate more when I get back next week. > > Thanks, > > Ilya > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
