The flatten operation is implemented by writing zero bytes to each object within a clone image. This causes librbd to copyup the backing object from the parent image to the clone image. A copyup is just a guarded write that will not write to the clone if the object already exists (i.e. new data has already been written to clone).
Without the deep-flatten changes, when you attempt to flatten a clone with snapshots, the copyup "write" operation only affects the HEAD version of the clone image objects. Therefore, post-flatten, if I attempt to read from a snapshot taken before the flatten copyups, it would appear as if the object doesn't exist (since it doesn't exist until the HEAD version). That is why flatten would not previously detach from the parent image if you have snapshots -- since reading from your snapshot might result in a missing object that exists within the parent. The change implemented by deep-flatten modifies the copyup logic to simulate that the write operation occurred before all snapshots were taken. Therefore, the clone object will now be visible within all snapshots (not just the HEAD version). This new copyup logic is actually always enabled in infernalis, regardless of whether or not you enable deep-flatten. The only purpose for the "deep-flatten" feature bit is to prevent pre-infernalis clients from writing to the image with the old copyup logic. When it's enabled, we know that it is safe to detach a clone from a parent image even if snapshots exist due to the changes to copyup. -- Jason Dillaman ----- Original Message ----- > From: "Zhongyan Gu" <[email protected]> > To: [email protected] > Sent: Thursday, October 22, 2015 5:11:56 AM > Subject: how to understand deep flatten implementation > Hi Jason, > I am a ceph user. I see you are the main developer in rbd module and one of > the features you worked on is deep flatten, so I turn to you for help. > I tried to figure out how deep flatten works, but failed. Things begin like > that: > I used the firefly version to do the test: > Image —make_snap->clone--> volume1 --make_snap--> flatten volume1. > Then I found volume1’s snap still has parent which points image’s snap. > Flatten didn’t decouple the snapshots. > I noticed from ceph website that a feature named deep flatten will implement > those things. > I think the only missed step is deregister child clone from parent. > However, when I reviewed the deep flatten implementation, the logic is far > from what I thought. > Could you please explain why a copyup need to send an empty snap context? > I read the description of http://tracker.ceph.com/issues/10154 , > What does it mean “ the osd will treat it as an old write and will logically > replace all versions of the object that did not exist ” > Looking forward to your reply. > Cheers > Cory _______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
