OpenZFS의 설명서에 보면 dRAID에 대해서 다음과 같이 설명하고 있습니다.
dRAID는 레이드의 장점을 유지하면서 더 빠르게 복구할 수 있도록 통합 분산 핫 스페어를 제공하는 레이드의 변형입니다. dRAID vdev는 각각 D개의 데이터 디바이스와 P개의 패리티 디바이스로 구성된 여러 개의 내부 레이드 그룹으로 구성됩니다. 이러한 그룹은 사용 가능한 디스크 성능을 최대한 활용하기 위해 모든 하위 그룹에 분산되어 있습니다. 이를 패리티 디클러스터링이라고 하며 최근 활발히 연구되고 있는 분야입니다. 아래 이미지는 단순화되었지만 dRAID와 레이드의 주요 차이점을 설명하는 데 도움이 됩니다.

출처 : https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html
기술용어로 짤막하게 줄이면 “dRAID는 레이드와 동일한 수준의 중복성 및 성능을 제공하는 동시에 빠른 통합 분산 스페어도 제공할 수 있습니다.” 정도가 될 것 같습니다.
뭔가 살짝 좋아보이기는 한 것 같습니다.
그래서 좀 더 찾아봤습니다. 그리고 오픈소스 스토리지로 유명한 TrueNAS 설명서에 보면 “dRAID 사용 권장 사항”
Shell
x
스토리지 효율성에 대한 우려로 인해 dRAID vdev 레이아웃은 TrueNAS 스토리지 어레이에 장애가 자주 발생할 것으로 예상되는 디스크가 다수(100개 이상) 연결되어 있고 어레이에 대용량 데이터 블록을 저장하는 매우 특정한 상황에서만 권장됩니다. SSD에 배포하는 경우, 비디오 프로덕션 및 일부 HPC 스토리지와 같은 고성능 대용량 워크로드에 dRAID가 실행 가능한 옵션이 될 수 있지만, 프로덕션에 적용하기 전에 구성을 철저히 테스트해야 합니다.
현재 dRAID와 RAIDz vdev 레이아웃 간의 조사에 따르면 모든 일반적인 사용 사례 시나리오, 특히 작은 블록의 데이터가 저장되는 경우 RAIDZ 레이아웃이 데이터를 더 효율적으로 저장하는 것으로 나타났습니다. dRAID는 주로 작은 블록의 데이터를 읽고 쓰는 애플리케이션에는 적합하지 않으며, VMware 및 데이터베이스와 같이 미러 및 RAIDz vdev에 더 적합한 애플리케이션에는 적합하지 않습니다.
일반적으로 복구 시간을 크게 줄이고 풀을 더 빨리 정상 상태로 되돌릴 필요가 있는 경우 dRAID를 고려하세요. dRAID의 구현은 매우 새롭고 RAIDZ와 같은 정도로 테스트되지 않았습니다. 스토리지 프로젝트가 위험을 감당할 수 없다면 dRAID가 더 잘 정착되고 폭넓게 테스트될 때까지 기다리는 것이 좋습니다.
출처 : https://www.truenas.com/docs/references/draidprimer/
간단히 줄여보면 SSD 디스크가 100개 미만인 경우는 추천 사항이 아닙니다.
그래서 제 결론은 단독 서버로 사용하는 시나리오에서는 비추천입니다.