Re: OSD after OS reinstallation.

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

 



On Wed, Feb 20, 2019 at 8:40 AM Анатолий Фуников
<anatoly.funikov@xxxxxxxxxxx> wrote:
>
> Thanks for the reply.
> blkid -s PARTUUID -o value /dev/sdf1 shows me nothing, but blkid /dev/sdf1 shows me this: /dev/sdf1: UUID="b03810e4-dcc1-46c2-bc31-a1e558904750" TYPE="xfs"

I think this is what happens with a non-gpt partition. GPT labels will
use a PARTUUID to identify the partition, and I just confirmed that
ceph-volume will enforce looking for PARTUUID if the JSON
identified a partition (vs. an LV).

>From what I briefly researched it is not possible to add a GPT label
on a non-gpt partition without losing data.

My suggestion (if you confirm it is not possible to add the GPT label)
is to start the migration towards the new way of creating OSDs

>
> ср, 20 февр. 2019 г. в 16:27, Alfredo Deza <adeza@xxxxxxxxxx>:
>>
>> On Wed, Feb 20, 2019 at 8:16 AM Анатолий Фуников
>> <anatoly.funikov@xxxxxxxxxxx> wrote:
>> >
>> > Hello. I need to raise the OSD on the node after reinstalling the OS, some OSD were made a long time ago, not even a ceph-disk, but a set of scripts.
>> > There was an idea to get their configuration in json via ceph-volume simple scan, and then on a fresh system I can make a ceph-volume simple activate --file /etc/ceph/osd/31-46eacafe-22b6-4433-8e5c-e595612d8579.json
>> > I do ceph-volume simple scan /var/lib/ceph/osd/ceph-31/, and got this json: https://pastebin.com/uJ8WVZyV
>> > It seems everything is not bad, but in the data section I see a direct link to the device /dev/sdf1, and the uuid field is empty. At the same time, in the /dev/disk/by-partuuid directory I can find and substitute this UUID in this json, and delete the direct link to the device in this json.
>> > The question is: how correct is it and can I raise this OSD on a freshly installed OS with this fixed json?
>>
>> It worries me that it is unable to find a uuid for the device. This is
>> important because paths like /dev/sdf1 are ephemeral and can change
>> after a reboot. The uuid is found by running the following:
>>
>>         blkid -s PARTUUID -o value /dev/sdf1
>>
>> If that is not returning anything, then ceph-volume will probably not
>> be able to ensure this device is brought up correctly. You can correct
>> or add to anything in the JSON after a scan and rely on that, but then
>> again
>> without a partuuid I don't think this will work nicely
>>
>> > _______________________________________________
>> > ceph-users mailing list
>> > ceph-users@xxxxxxxxxxxxxx
>> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
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