MS Windows. 이 얼마나 은혜로운 OS인가! 하지만 저장장치 애호가의 입장으로 보면, 불투명하고 포텐셜도 낮은 OS입니다.

물론, Redesign된 NVMe Stack이 베카 단계를 벗어나 드디어 Windows Server 2025에 정식 출시가 되며 성능 향상을 얻을 수 있었습니다.

이를 테스트하기 위해서 Insider program을 준비하려고 하였는데, 그럴 필요가 없어졌네요. 다만, 작성할 글들이 밀려있는 상태라 비교 벤치마크는 내년에 진행할 예정입니다.

발표한지 일주일도 지나지 않은 HW 가속 BitLocker도 함께 말이죠.

사실 이쪽은 TCG Opal과 함께 소개하는 편이 좋은가, 고민도 되네요.

아무튼, 윈도우가 우리 일반 소비자와 매우 밀접한 연관이 있는 것은 분명한 사실입니다. 그래서 많은 cSSD들의 스펙 시트는 윈도우 기준으로 측정되지만, 리눅스에서도 측정하는 경우가 종종 있죠. 다시 말하자면, 양쪽을 크게 차별하는 모습은 아닙니다.

그렇게 생각했어요.

이 친구를 벤치마크 해보기 전에는요.

오늘의 리뷰 대상은 에센코어의 C910입니다.


4TB 모델이며, 컨트롤러는 PCIe 4.0 x4 인터페이스를 지원하고 8채널 디램리스의 리얼텍 RTS5772, NAND는 하이닉스 V6 TLC 512Gb 다이를 HDP로 하여 4개의 칩을 사용했습니다.


데이터시트는 약간 번역기를 돌린 느낌이 납니다. 좌측엔 4TB가 보이지 않지만, 우측의 성능표에선 확인할 수 있네요.

컨트롤러의 언급은 없으며, 3D TLC NAND임을 명시하고 있습니다.


역시 HMB를 지원합니다. 64MiB가 할당되었네요



사실, HMB에 대한 정보를 얻기 전까지 많은 사투가 있었습니다.

아무 생각 없이 리눅스로 부팅하면 SSD가 인식되지 않기 때문이죠.


다행이라고 해야할지, 동일한 문제를 겪는 사람이 있었고, 대응책을 찾을 수 있었습니다.

바로 윈도우를 살짝 맛보게 한다음에 리눅스로 틀어버리는거죠.

실제로 이렇게 해보니 잘 동작했습니다.


그런데 또 문제가 생겼어요.

드라이브의 연결이 어느 순간 갑작스럽게 중단됩니다.

아마 벤치마크를 진행하며 nvme format 명령어를 사용할 때 드라이브가 떨어지는 것 같은데, 제가 직접 명령어를 날려보니 안 떨어지더라고요.


싸우자는 거냐.

아무튼, 이러한 이유로 이 친구의 벤치마크를 진행하며 재부팅을 약 5번 시도했습니다.

동일한 컨트롤러를 사용한 다른 SSD에서도 리눅스에서 문제가 발생하는 것으로 보이는데, 이쯤되면 꽃게의 잘못이 확실해 보입니다.


자 그럼 본래의 리뷰로 돌아갑시다. CDI 캡쳐입니다.

smartctl이나 nvme-cli의 출력은 블로그에 있는 링크를 통해 확인하실 수 있습니다.

약간 놀랐던 것은, warning temperature가 섭씨 100도, critical temperature가 섭씨 110도로 지정되어 있던 것 입니다.

부담스러울 정도로 높은데, 내열에 자신있는걸까요?



그럼 성능 측정 결과를 제시해봅시다. 우선 유의사항부터.

*Windows 25H2(26200.6899)에 종속되는 도구들을 제외하고는 모두 FIO 3.41을 통해 Rocky Linux 10(6.12.0-55.12.1.el10_0)에서 실행되며, io_uring과 Polling을 적극적으로 활용합니다. 또한, 양쪽 다 기본 Inbox Driver를 사용합니다.

*AMD 9600X를 사용하며, DUT는 STRIX B850I의 PEG슬롯(5.0 x16)에 직결합니다. ASPM이나 C-State와 관련된 옵션은 전부 껐습니다.

*모든 데이터를 보실 때는 그래프의 X축과 Y축을 유심히 봐주세요.

*자세한 내용은 원글 참고 부탁드립니다.

네 여기까지.


CDM은 스펙시트의 성능 (5200/4800MBps) (540k/600k IOPS)를 잘 충족시키는 모습입니다.


3DM과 SPECworkstation에서는 0%와 75% 사이에 의미있는 점수차가 나지 않았습니다.

그나저나 많은 워크로드에서 75%가 채워진 P3 Plus 2TB보다 SPECworkstation의 성능이 낮은 건 좀 실망스럽네요.


다음은 Fill Drive 1회차입니다. 최대 1.5TB에 육박하는 SLC 캐시입니다만, 벗어나면 속도가 안정되지 않고 무섭게 요동칩니다.


다음은 2화차입니다. GC의 난도가 낮지만, 여전히 요동치고 있는 모습입니다.

조금이라도 의미를 찾자면, 1000초와 6000초 부근에서 유의미한 속도 변화가 보이긴합니다.

문제는 하도 날뛰어서 분석이 너무 어려워지네요. 기존의 제 접근법과는 다르게 봐야할 것 같은데, 조금 정이 떨어진 상태입니다.

넘기도록 하죠.

전체 평균 속도와 1회차의 하위 1% 속도입니다. 그래도 TLC라고 QLC보단 선방해주었네요.


동기쓰기 성능입니다.


그럼 읽쓰기 비율에 따른 성능 변화와 가중치 그래프입니다.

가중치를 준 그래프에서 C910은 970 PRO와 상당히 유사한 모습을 보여줍니다.


디램리스의 단점을 보여주기 위한 벤치마크입니다. DRAM이 있는 SSD들은 이 벤치마크에서 일관된 성능을 보여줍니다.

DRAMless SSD들은 위 그래프의 P3 Plus처럼 HMB 영역에 영향을 받게되죠.

그런데 C910은 그냥 일관되게 저성능입니다.

HMB 활성화 여부는 앞에서 이미 확인했는데 말이죠. Fill Drive 결과도 그렇고 이 정도면 플래그십? SATA SSD가 생각납니다.

물론, 리눅스에서 발생하는 문제라고 생각됩니다. 일단 CDM에서는 스펙대로 나왔으니까요.

그렇다고 이 벤치마크를 CDM으로 하는 것은 좀 무리가 있단 말이죠.


다음은 SLC 캐시 회복에 관한 그래프입니다. 휴식시간이 30초 부여될 때부터 SLC캐시의 유의미한 회복이 이루어지는 것으로 보입니다.


마지막은 부팅용 eSSD를 위한 벤치마크입니다. P3 Plus에 이어 C910도 실패했습니다.



C910은 좀 실망스러웠습니다. 리눅스에서 꽤 문제가 발생하는 것으로 보이며, SLC캐시 외부의 성능도 일관되지 않습니다.

고용량 SLC 캐시? 좋죠. 현대 cSSD의 트렌드이며, 일반 소비자 워크로드에 상당히 좋은 효과를 낼 수 있습니다.

그렇다고 SLC 캐시 외부를 완전히 망쳐놓으라는 의미는 아닌데 말이죠...


혹시 모르죠? 이것도 리눅스와의 궁합이 문제일지도. 윈도우라면 문제 없는 분들도 많다는 주장이 나올 수 있겠지만, 소비자의 가능성을 제한해버리고 호환성과 안정성의 문제를 확인할 수 있었던 이번 SSD는 개인적으로 최악으로 꼽고 싶습니다.

읽어주셔서 감사합니다.

다음 리뷰는 내년부터 일주일 간격으로 업로드하는 것이 목표입니다. 연말 잘 보내시길 바랍니다.



*해당 드라이브를 빌려주신 지인분께 이 리뷰로 감사인사를 전합니다.