Peter nailed this on the head. You shouldn't setup your journals using /dev/sdx naming. You should use /dev/disk/by-partuuid or something similar.
This way it will not matter what letter your drives are assigned on reboot. Your /dev/sdx letter assignments can change on a reboot regardless if you changed your kernel or ceph version.
David Turner |
Cloud Operations Engineer |
StorageCraft
Technology Corporation 380 Data Drive Suite 300 | Draper | Utah | 84020 Office: 801.871.2760 | Mobile: 385.224.2943 |
If you are not the intended recipient of this message or received it erroneously, please notify the sender and delete it, together with any attachments, and be advised that any dissemination or copying of this message is prohibited. |
________________________________________
From: ceph-users [ceph-users-bounces@xxxxxxxxxxxxxx] on behalf of Peter Maloney [peter.maloney@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, November 01, 2016 3:18 AM
To: ceph-users@xxxxxxxxxxxxxx
Subject: Re: After kernel upgrade OSD's on different disk.
On 11/01/16 00:10, jan hugo prins wrote:
> After the kernel upgrade, I also upgraded the cluster to 10.2.3 from
> 10.2.2.
> Let's hope I only hit a bug and that this bug is now fixed, on the other
> hand, I think I also saw the issue with a 10.2.3 node, but I'm not sure.
It's not a bug for disks to change names... you should never expect them
to be static for any Linux system, ceph or not. As Henrik has already
said, this is normal.
> On 10/31/2016 11:41 PM, Henrik Korkuc wrote:
>> this is normal. You should expect that your disks may get reordered
>> after reboot.
>> On 16-10-31 18:32, jan hugo prins wrote:
>>> My idea to fix this is to use the Disk UUID instead of the dev name
>>> (/dev/disk/by-uuid/<uuid> instead of /dev/sda) when activating the disk.
>>> But I really don't know if this is possible.
>>>
>>> Could anyone tell me if I can prevent this issue in the future?
This is what I would do... always use something that doesn't change,
such as the filesystem UUID, GPT partlabel, GPT partuuid, etc.
And I wouldn't use udev the way the others suggested... I think it's
much simpler to use a static name than make it enforce that the normally
dynamic names are static.
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
From: ceph-users [ceph-users-bounces@xxxxxxxxxxxxxx] on behalf of Peter Maloney [peter.maloney@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, November 01, 2016 3:18 AM
To: ceph-users@xxxxxxxxxxxxxx
Subject: Re: After kernel upgrade OSD's on different disk.
On 11/01/16 00:10, jan hugo prins wrote:
> After the kernel upgrade, I also upgraded the cluster to 10.2.3 from
> 10.2.2.
> Let's hope I only hit a bug and that this bug is now fixed, on the other
> hand, I think I also saw the issue with a 10.2.3 node, but I'm not sure.
It's not a bug for disks to change names... you should never expect them
to be static for any Linux system, ceph or not. As Henrik has already
said, this is normal.
> On 10/31/2016 11:41 PM, Henrik Korkuc wrote:
>> this is normal. You should expect that your disks may get reordered
>> after reboot.
>> On 16-10-31 18:32, jan hugo prins wrote:
>>> My idea to fix this is to use the Disk UUID instead of the dev name
>>> (/dev/disk/by-uuid/<uuid> instead of /dev/sda) when activating the disk.
>>> But I really don't know if this is possible.
>>>
>>> Could anyone tell me if I can prevent this issue in the future?
This is what I would do... always use something that doesn't change,
such as the filesystem UUID, GPT partlabel, GPT partuuid, etc.
And I wouldn't use udev the way the others suggested... I think it's
much simpler to use a static name than make it enforce that the normally
dynamic names are static.
_______________________________________________
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