On 19-10-2017 14:14, Alfredo Deza wrote:
If these properties also mean device information (vendor, size,
solid/rotational, etc...) it could help
to better map/detect an OSD replacement since clusters tend to have a
certain level of
homogeneous hardware: if $brand, and $size, and $rotational etc...
- A daemon (e.g., ceph-osd-autoreplace) that runs on each machine or a
tool that is triggered by udev. It would check for new, empty devices
appearing in the locations (as defined by the by-path string) previously
occupied by OSDs that are down. If that happens, it can use 'ceph osd
safe-to-destroy' to verify whether it is safe to automatically rebuild
that OSD. (If not, it might want to raise a health alert, since it's
possible the drive that was physically pulled should be preserved until
the cluster is sure it doesn't need it.)
systemd has some support for devices, so we might not even need a
daemon, but more a unit that can
depend on events already handled by systemd (would save us from udev).
FreeBSD does not have systemd. 8-)
I'm inclined to say luckily, but then that may be my personal bias.
I don't like "automagic" tools like Udev or systemd tinkering with my
disks.
As Alan says, in ZFS one can designate hot-standby. But even there I
prefer to be alerted and then manually intervene.
A hot-swap daemon that gets instructed to only use explicitly and fully
enumerated disk might be something to trust. So something matching
disk-serial number would be oke.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
