Deepsea can't detect if a disk is an SSD/HDD if it sits behind a RAID Controller.

[jschmid1]

So far I heard from a couple of people wanting to deploy with a RAID setup. That won't work with the current method of detecting solid states..

The only tool that is capable of detecting the correct type is smartctl megaraid.

We either want to change the way we detect the the disktype or add some overwrite capabilities.

[swiftgist]

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?

[jschmid1]

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.

[jschmid1]

++ 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)

[smithfarm]

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

[jschmid1]

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.

[jschmid1]

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

[jschmid1]

fixed in #73

[BlaineEXE]

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.

[swiftgist]

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.