-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my experience, for safety, you should consider /dev/sd assignments to be randomly assigned during boot. You may also want to be wary about using /dev/disk/by-path. I have had pci bus/slot numbering change after a kernel upgrade. From your description, I will bet the scsi id's are being assigned by enumeration at boot/insertion time, which means you should consider them random as well. The only thing you can trust is the by-id (since it include the disk serial number), and the various uuid and labels. What problem are you trying to solve here? Do you just want to know what OSD is in what slot, or something else? On 04/21/2017 04:37 AM, Ovidiu Poncea wrote: > Hi Felix, > > I'm wondering if the assignments changes if you reset the BIOS. > Also, when you insert a new disk in between what happens to the old > disks, do they keep their assignments (or as Mehmet said, do you > get an in-between number)? If not you may get into worse problems > if disks fail or you add new disks. > > We also switched from /dev/sd* nodes to /dev/disk/by-path/* as we > had trouble pinning /dev/sd* devices to the same slot but we are > not yet sure if it always works. For us, since servers are > different, the solution is to first boot the node (ubuntu/fedora > live), get the disk assignments, configure puppet for each node (we > are using puppet) and do a remote install with the correct paths > but this is just for the initial install. > > Regards, > > Ovidiu > > > On 04/21/2017 01:20 AM, Mehmet wrote: >> Hi Felix, >> >> What happens when you Restart the Server - is the numbering then >> identical? >> >> I have this behavior on Intel Server and when i put additional >> Disks in Runtime, the numbering increases but i expect to get a >> Number from between two Slots (of course when i put a Disk >> between this slots). >> >> Hope you understand what i mean :) >> >> HTH Mehmet >> >> Am 20. April 2017 09:19:32 MESZ schrieb "Stolte, Felix" >> <f.stolte@xxxxxxxxxxxxx>: >> >> Hello cephers, >> >> is anyone using Fujitsu Hardware for Ceph OSDs with the PRAID >> EP400i Raidcontroller in JBOD Mode? We are having three identical >> servers with identical Disk placement. First three Slots are SSDs >> for journaling and remaining nine slots with SATA Disks. Problem >> is, that in Ubuntu (and I would guess in any other distribution >> as well) the disk paths for the same physical drive slot differ >> between the three servers. For example on Server A first disk is >> identified as "pci-0000:01:00.0-scsi-0:0:14:0" and as >> "pci-0000:01:00.0-scsi-0:0:17:0" on the other. This makes >> provisioning osds nearly impossible. Anyone ran into the same >> issue an knows how to fix this? Fujitsu support couldn't help (in >> fact they did not know, that you can put the controller in JBOD >> mode ...). I actvated JBOD via the "Enable JBOD" option in the >> controller management menu of the praid ep400i raid controller. >> >> Cheers Felix >> >> >> Felix Stolte IT-Services E-Mail: f.stolte@xxxxxxxxxxxxx Internet: >> http://www.fz-juelich.de >> >> Forschungszentrum Juelich GmbH 52425 Juelich Sitz der >> Gesellschaft: Juelich Eingetragen im Handelsregister des >> Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: >> MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. >> Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke >> (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. >> Sebastian M. Schmidt >> >> >> >> _______________________________________________ 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 > - -- Tony Lill, OCT, ajlill@xxxxxxxxxxxxxxxxxxx President, A. J. Lill Consultants (519) 650 0660 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 - --------------- http://www.ajlc.waterloo.on.ca/ ---------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlj6EjoACgkQGS8yZq1uvxCKnwCdGPo5O51pywRbpjPG6NFDpiaX kpYAni8gjrTGoXhktqxqh621F4f9LYiH =19I2 -----END PGP SIGNATURE----- _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |