Re: ONE pg deep-scrub blocks cluster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



How Mehmet

OK so it does come from a rados put. 

As you were able to check the VM device objet size is 4 MB. 

So we'll see after you have removed the object with rados -p rbd rm. 

I'll wait for an update. 

JC

While moving. Excuse unintended typos.

> On Aug 29, 2016, at 14:34, Mehmet <ceph@xxxxxxxxxx> wrote:
> 
> Hey JC,
> 
> after setting up the ceph-cluster i tried to migrate an image from one of our production vm into ceph via
> 
> # rados -p rbd put ...
> 
> but i have got always "file too large". I guess this file
> 
> # -rw-r--r-- 1 ceph ceph 100G Jul 31 01:04 vm-101-disk-2__head_383C3223__0
> 
> is the result of this :) - did not thought that there will be something stay in ceph after the mentioned error above.
> Seems i was wrong...
> 
> This could match the time where the issue happened first time...:
> 
> 1. i tried to put via "rados -p rbd put..." this did not worked (tried to put a ~400G file...)
> 2. after ~ 1 week i see the blocked requests after first running "deep-scrub" (default where ceph starts deep-scrubbing)
> 
> I guess the deleting of this file should solve the issue.
> Did you see my mail where i wrote the test results of this?
> 
> # osd_scrub_chunk_max = 5
> # osd_deep_scrub_stride = 1048576
> 
> Only corner note.
> 
>> This seems more to me like a pure radios object of 100GB that was
>> uploaded to the cluster. From the name it could be a VM disk image
>> that was uploaded as an object. If it was an RBD object, it’s size
>> would be in the boundaries of an RBD objects (order 12=4K order
>> 25=32MB).
> 
>> Verify that when you do a "rados -p rbd ls | grep vm-101-disk-2”
>> command, you can see an object named vm-101-disk-2.
> 
> root@:~# rados -p rbd ls | grep vm-101-disk-2
> rbd_id.vm-101-disk-2
> vm-101-disk-2
> 
>> Verify if you have an RBD named this way “rbd -p rbd ls | grep vm-101-disk-2"
> 
> root@:~# rbd -p rbd ls | grep vm-101-disk-2
> vm-101-disk-2
> 
>> As I’m not familiar with proxmox so I’d suggest the following:
>> If yes to 1, for security, copy this file somewhere else and then to a
>> rados -p rbd rm vm-101-disk-2.
> 
> root@:~# rbd -p rbd info vm-101-disk-2
> rbd image 'vm-101-disk-2':
>        size 400 GB in 102400 objects
>        order 22 (4096 kB objects)
>        block_name_prefix: rbd_data.5e7d1238e1f29
>        format: 2
>        features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
>        flags:
> 
> The VM with the id "101" is up and running. This is using "vm-101-disk-2" as disk - i have moved the disk sucessfully in another way :) (same name :/) after "rados put" did not worked. And as we can see here the objects for this image also exists within ceph
> 
> root@:~# rados -p rbd ls | grep "rbd_data.5e7d1238e1f29" | wc -l
> 53011
> 
> I assumed here to get 102400 objects but as ceph is doing thin provisining this should be ok.
> 
>> If no to 1, for security, copy this file somewhere else and then to a
>> rm -rf vm-101-disk-2__head_383C3223__0
> 
> I should be able to delete the mentioned "100G file".
> 
>> Make sure all your PG copies show the same content and wait for the
>> next scrub to see what is happening.
> 
> Will make a backup of this file and in addition from the vm within proxmox tomorrow on all involved osds and then start a deep-scrub and of course keep you informed.
> 
>> If anything goes wrong you will be able to upload an object with the
>> exact same content from the file you copied.
>> Is proxmox using such huge objects for something to your knowledge (VM
>> boot image or something else)? Can you search the proxmox mailing list
>> and open tickets to verify.
> 
> As i already wrote in this eMail i guess that i am the cause for this :*( with the wrong usage of "rados put".
> Proxmox is using librbd to talk with ceph so it should not be able to create such a large one file.
> 
>> And is this the cause of the long deep scrub? I do think so but I’m
>> not in front of the cluster.
> 
> Let it see :) - i hope that my next eMail will close this issue.
> 
> Thank you very much for your help!
> 
> Best regards,
> - Mehmet
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux