Yes, when you flatten an image, the snapshots will remain associated to the original parent. This is a side-effect from how librbd handles CoW with clones. There is an open RBD feature request to add support for flattening snapshots as well. -- Jason Dillaman Red Hat dillaman@xxxxxxxxxx http://www.redhat.com ----- Original Message ----- From: "Matthew Monaco" <matt@xxxxxxxxx> To: "Jason Dillaman" <dillaman@xxxxxxxxxx> Cc: ceph-users@xxxxxxxxxxxxxx Sent: Monday, April 13, 2015 2:50:17 PM Subject: Re: rbd: incorrect metadata On 04/13/2015 07:51 AM, Jason Dillaman wrote: > Can you add "debug rbd = 20" to your config, re-run the rbd command, and > paste a link to the generated client log file? > I set both rbd and rados log to 20 VOL=volume-61241645-e20d-4fe8-9ce3-c161c3d34d55 SNAP="$VOL"@snapshot-d535f359-503a-4eaf-9e71-48aa35b28d0c rbd -p volumes children "$SNAP" &> http://hastebin.com/lalajofoqu rbd -p volumes snap unprotect "$SNAP" &> http://hastebin.com/vibonepeme There are other errors in there about not looking up $SNAP's parent and name for pool id 4 (which usage to be "images"). What happened was "images" had way too many PGs, so I flattened all of the rbds in "volumes", copied over to a new "images" pool and then deleted the old one. When I flattened the volumes, the snapshots remained associated with the original parent (is this a bug/limitation/expected...?). I didn't mind just deleting the snapshots bc I assumed they were borked. However with this particular snapshot "$SNAP", this thing happened where the metadata broke and I can't unprotected it. > The rbd_children and rbd_directory objects store state as omap key/values, > not as actual binary data within the object. You can use "rados -p rbd > listomapvals rbd_directory/rbd_children" to see the data within the files. > Ah, thanks for the info. I guess I need to use rmomapkey on rbd_children. _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |