Hi Jason.

Well, I don't tried that, because I am afraid to break something :/ I don’t 
really understand what are you doing there :(

Thanks anyways. 

Regards
Torsten

> Am 31.07.2020 um 16:46 schrieb Torsten Ennenbach <tennenb...@gridscale.io>:
> 
> Wow,
> 
> Thx I will try this asap. Thats a … solution…
> Unfortunately I can’t, tell you how this is happened :(
> 
> As far as I remember, this images was a cloned snapshot, without deep-flatten 
> active as feature.
> 
> Thx Jason.
> 
> --
> 
> 
>> Am 31.07.2020 um 14:43 schrieb Jason Dillaman <jdill...@redhat.com 
>> <mailto:jdill...@redhat.com>>:
>> 
>> On Fri, Jul 31, 2020 at 8:10 AM Torsten Ennenbach
>> <tennenb...@gridscale.io <mailto:tennenb...@gridscale.io>> wrote:
>>> 
>>> Hi Jason
>>> 
>>>> Am 31.07.2020 um 14:08 schrieb Jason Dillaman <jdill...@redhat.com 
>>>> <mailto:jdill...@redhat.com>>:
>>>> 
>>>> rados
>>>> -p rbd listomapvals rbd_header.f907bc6b8b4567
>>> 
>>> rados -p rbd listomapvals rbd_header.f907bc6b8b4567
>>> error getting omap keys rbd/rbd_header.f907bc6b8b4567: (2) No such file or 
>>> directory
>> 
>> Ack. This can be fixed, but do you have any idea how the child image
>> was removed? The removal process should delete its link to the parent
>> before it's actually deleted (same w/ the flatten process). If there
>> is some bug allowing images to slip through, I would like to fix it.
>> 
>> First step to removing that link manually will be to get the image id
>> of the "delete-me-please" image via "rbd info". You can then run the
>> following to find the matching key entry for that image id (it's
>> buried in a binary blob):
>> 
>> (looking for 106e8126b1f2 in my example)
>> $ rados -p rbd listomapvals rbd_children
>> <..... snip ....>
>> key (32 bytes):
>> 00000000  02 00 00 00 00 00 00 00  0c 00 00 00 31 30 36 65  
>> |............106e|
>> 00000010  38 31 32 36 62 31 66 32  04 00 00 00 00 00 00 00  
>> |8126b1f2........|
>> 00000020
>> 
>> value (19 bytes) :
>> 00000000  01 00 00 00 0b 00 00 00  31 30 37 37 64 32 36 64  
>> |........1077d26d|
>> 00000010  38 66 64                                          |8fd|
>> 00000013
>> < .... snip .... >
>> 
>> You will then need to use hexedit (or something similar) to create a
>> file w/ that exact binary key value that matches your image id. Below
>> I've tweaked the hex from above key to match the xxd import format:
>> 
>> $ cat <<EOF > key.txt
>>> 00000000: 02 00 00 00 00 00 00 00 0c 00 00 00 31 30 36 65  ............106e
>>> 00000010: 38 31 32 36 62 31 66 32 04 00 00 00 00 00 00 00  8126b1f2........
>>> EOF
>> $ xxd -r -g 1 key.txt key.bin
>> $ xxd -g 1  key.bin
>> 00000000: 02 00 00 00 00 00 00 00 0c 00 00 00 31 30 36 65  ............106e
>> 00000010: 38 31 32 36 62 31 66 32 04 00 00 00 00 00 00 00  8126b1f2........
>> 
>> You can now provide that binary key file to rados to remove the offending 
>> key:
>> 
>> $ rados -p rbd rmomapkey rbd_children --omap-key-file key.bin
>> 
>> 
>>> 
>>> Torsten
>>> _______________________________________________
>>> ceph-users mailing list -- ceph-users@ceph.io <mailto:ceph-users@ceph.io>
>>> To unsubscribe send an email to ceph-users-le...@ceph.io 
>>> <mailto:ceph-users-le...@ceph.io>
>>> 
>> 
>> 
>> -- 
>> Jason
>> 
> 

_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to