Hi,
Would I take this to understand that this may be a known issue with udev
on RHEL then? We will for now add them to the fstab.
Thanks,
derek
On 1/25/14, 9:23 PM, Michael J. Kidd wrote:
While clearly not optimal for long term flexibility, I've found that
adding my OSD's to fstab allows the
Hi Derek,
Would like to get to the bottom of your problem. Is it that the monitors
don't start after a reboot? Is there an error in
/var/log/ceph/ceph-mon.`hostname`.log?
sage
On Mon, 27 Jan 2014, Derek Yarnell wrote:
Hi,
Would I take this to understand that this may be a known issue
On Mon, 27 Jan 2014, Derek Yarnell wrote:
Hi Sage,
Our clusters are slightly different but no the monitors start just fine.
On our test and rgw clusters we run monitors co-located with our OSDs.
The monitors start just fine. My understanding is that when booting
the hosts detect a disk
Hi Sage,
Our clusters are slightly different but no the monitors start just fine.
On our test and rgw clusters we run monitors co-located with our OSDs.
The monitors start just fine. My understanding is that when booting
the hosts detect a disk hot-plug event in udev via the
Our best guess so far is that this line is not matching the underlying
disk that is getting hotplugged (95-ceph-osd.rules). Is
ID_PART_ENTRY_TYPE just the partition UUID or are we not understanding
identifier correctly?
ENV{ID_PART_ENTRY_TYPE}==4fbd7e29-9d25-41b8-afd0-062c0ceff05d,
This fix has been merged, thanks Derek!
sage
On Mon, 27 Jan 2014, Derek Yarnell wrote:
Our best guess so far is that this line is not matching the underlying
disk that is getting hotplugged (95-ceph-osd.rules). Is
ID_PART_ENTRY_TYPE just the partition UUID or are we not understanding
While clearly not optimal for long term flexibility, I've found that adding
my OSD's to fstab allows the OSDs to mount during boot, and they start
automatically when they're already mounted during boot.
Hope this helps until a permanent fix is available.
Michael J. Kidd
Sr. Storage Consultant
