On Thu, Feb 21, 2019 at 2:34 AM Анатолий Фуников <anatoly.funikov@xxxxxxxxxxx> wrote: > > It's strange but parted output for this disk (/dev/sdf) show me that it's GPT: > > (parted) print > Model: ATA HGST HUS726020AL (scsi) > Disk /dev/sdf: 2000GB > Sector size (logical/physical): 512B/4096B > Partition Table: gpt > > Number Start End Size Type File system Flags > 2 1049kB 1075MB 1074MB ceph journal > 1 1075MB 2000GB 1999GB xfs ceph data > The problem is that if there is no PARTUUID ceph-volume can't ensure what device is the one actually pointing to data/journal. Being 'GPT' alone will not be enough here :( > ср, 20 февр. 2019 г. в 17:11, Alfredo Deza <adeza@xxxxxxxxxx>: >> >> 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
 |