Deepsea can't detect if a disk is an SSD/HDD if it sits behind a RAID Controller. about deepsea HOT 9 CLOSED

Is this mainly for those doing pass through? That is, the drives are not in a RAID configuration, these drives are simply connected to a RAID controller.

If somebody is actually using RAID 3 or RAID 5, what is the "right" answer? Suggest that the "device" be an OSD? That seems wrong. If it's RAID 0, then it's probably fine if not down right confusing to use both RAID and Ceph for redundancy. Any thoughts?

from deepsea.

Is this mainly for those doing pass through? That is, the drives are not in a RAID configuration, these drives are simply connected to a RAID controller.

I'm pretty sure that's the case here.

If somebody is actually using RAID 3 or RAID 5, what is the "right" answer? Suggest that the "device" be an OSD? That seems wrong.

Mh, in that case they surely don't want it to be treated as a regular OSD..

If it's RAID 0, then it's probably fine if not down right confusing to use both RAID and Ceph for redundancy. Any thoughts?

IIRC one reason to use RAID-1 arised from a need for reliability in latency/recovery time... Never heard the usecase of RAID-0 in ceph though -

Manual intervention might be needed here.

from deepsea.

++ If we solely rely on SMART's output we could also include checks for potential disk issues.

++ speed ( hwinfo: real 0m2.044s vs smartctl real 0m0.445s)

from deepsea.

@jschmid1 See https://fate.suse.com/321053

from deepsea.

thanks for the pointer @smithfarm

we might still want to consider doing a initial(before initial deployment) health check.
The regular checks should definitely go(stay) into ceph-mgr.

from deepsea.

++ adds portability as hwinfo is not available on other distros.

from deepsea.

fixed in #73

from deepsea.

I realize this request has already been merged and closed, but I have something we might consider here. libstoragemgmt (https://github.com/libstorage/libstoragemgmt) could be used here as a generic disk detection subsystem; the code overhead might be much smaller, and our testing requirements would be reduced since it's already tested.

Edit: I looked through the code and tests more fully, and it seems hwinfo, lshw, and smartctl provide the data. At first glance, I thought megacli, etc. might have been used. I'm not sure libstoragemgmt would be totally applicable here, but it is a good thing to be aware of. My team at HPE has pushed a lot of changes into it to make sure it works on ProLiant.

from deepsea.

I cannot recall the exact post, but when I was deciding what to use for hwinfo, something I read discouraged me from using libstoragemgmt. I am all for not reinventing wheels and if this does meet the requirements, then I am fine with migrating to it. However, I will prefer custom code over workarounds for anything lacking in a library. Generally, there's less to debug.

from deepsea.