Published in Review

ESSENCORE KLEVV CRAS C910 4TB

12월 23, 2025

리눅스라는 개념이 존재하지 않는 지루한 SSD [C910 4TB]

Change log
2025.12.31 - Gone Brain-dead on Linux 부분 내용 추가

Microsoft Windows! 많은 사람이 쓰고 있으며, 앞으로도 상당한 점유율을 차지할 것으로 생각되는 PC용 OS입니다. 하지만, 저장장치 애호가이자 리뷰어의 입장으로 볼 때는, 제약도 상당한 OS입니다. 당장 Linux와 비교하면 불투명하고, 측정할 수 있는 최대 성능도 비교적 낮기 때문이죠.

물론, 이전에 언급한 NVMe Stack Redesign의 결과물이 Windows Server 2025에 정식 출시되긴 했습니다. 여러 하드웨어 뉴스들이 퍼 나르기도 했고요. 개인적으로는 도입에 시간이 더 오래 걸릴 것으로 예상해, Insider program을 준비하려고 했으나, 그냥 Windows Server로 테스트를 진행하면 될 것 같아 다행입니다.

하지만, 작성해야 할 글들이 좀 밀려있는 상태라 내년 중으로 비교 벤치마크를 하려고 합니다. 현시점에서 발표한 지 일주일이 지나지 않은 HW가속 BitLocker와 함께 말이죠. 이쪽은 TCG Opal 등과 함께 소개하는 것이 맞는지 고민도 되긴 합니다.

아무튼, 이러한 Windows는 일반 소비자 시장에서 분명하게 신경 써야 할 부분이 맞습니다. 그럼에도 불구하고, 일부 SSD들의 스펙 시트는 Linux 기준으로 작성되기도 하는 등, 양쪽을 크게 차별하지 않는 모습을 자주 볼 수 있으며, 저도 크게 신경 쓰지 않았습니다.

오늘 리뷰할 C910을 벤치마크하기 전까지는 말이죠.

Appearance

우선, 처음으로 제공되는 것은 Bare Drive와 별도의 방열판입니다. 하지만, 이 SSD는 지인분으로부터 대여받았기에 방열판이 설치되어 있었으며, 생각보다 상당히 두꺼운 모습이었습니다.

후면에는 ESSENCORE, KLEVV, CRAS, C910, 4TB 등, 이 제품에 대한 정보들이 간단하게 보입니다. 특이한 부분이라고 해야 할까요, DC 3.3V는 명시되었지만, 전류값은 별도의 언급이 없습니다.

Internal Components

다시 한 번 더 언급하지만, 이 제품은 제가 직접 구매한 것이 아닌, 지인을 통해 대여받은 SSD입니다.

물론, 방열판은 초기에 별도로 제공되므로, 제거해도 보증과는 큰 상관이 없겠지만, 용량이 좀 크기도 하고 별도의 위험을 지고 싶진 않았습니다. 다행히, C910은 광고비를 상당히 쓰는지 여러 커뮤니티의 리뷰에서도 보이며, 비교적 저렴한 가격으로 풀린 적도 많아 개인 리뷰로도 자주 찾을 수 있는 물건입니다.

변명이 길었지만, 결국 Flash ID를 통해 내부 부품을 추정하겠습니다.

... 
Controller: Realtek RTS5772
Bank00: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank01: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank08: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank09: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank16: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank17: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank24: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank25: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank32: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank33: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank40: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank41: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank48: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank49: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank56: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die
Bank57: 0xad,0x7e,0x2a,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 2048Gb/CE 512Gb/die

컨트롤러는 Realtek RTS5772을 사용합니다. PCIe 4.0 x4 인터페이스를 허용하는 8채널 DRAMless 컨트롤러이며, RAYMX에 의하면 8CE와 1066MT/s의 인터페이스를 가지고 있다고 합니다.
개인적으로 가진 정보에서는 4CE, 1600MT/s이지만, 크게 신경 쓸 부분은 아닐 것이라 생각됩니다. 포지션도 비교적 저가형 시장을 노리는 것으로 보이고요.

저장매체는 SK hynix V6 128L TLC 512Gb를 사용했습니다. 64L+64L로 이루어졌으며, Toggle 4.0 1200MT/s 인터페이스를 지원합니다. 총 4개의 칩으로 구성되며, 하나의 칩은 16개의 Die가 패키징된 것(HDP)으로 보입니다. (512Gb *16) *4 = 4TB의 형식으로 용량을 구성하는 거죠.

Datasheet

이번엔 데이터시트를 봅시다. 첫인상은 묘하게 번역기를 돌렸다는 느낌을 받았습니다. 그 외에는 좌측에선 4TB 모델이 보이지 않지만, 우측은 보인다는 것도 특징이겠네요.

컨트롤러에 대한 직접적인 언급은 없으며, NAND Flash에 한정해 3D TLC NAND를 사용한다고 언급합니다. 보증은 5년에 2800TBW. 일반적인 TLC SSD에 비해 조금 더 넉넉하게 주었네요.

Notable Points

HMB (Host Memory Buffer)

DRAM은 실장되지 않았지만, HMB(Host Memory Buffer) 기능은 지원합니다. Linux에서 nvme get-feature 명령어를 사용하면, Host Memory Buffer Size (HSIZE): 16384임을 확인할 수 있습니다.

NVMe 표준 사양에 의하면 이 HSIZE는 곧바로 용량을 나타내는 것이 아닌, memory page size units를 통해 계산할 수 있습니다. 일반적으로 이는 4kiB이기에 16384를 곱해주면, 64MiB가 HMB로 할당되었다고 할 수 있겠습니다.

사실, dmesg로 더 간단하게 확인할 수도 있습니다. 아래에서는 다른 내용을 다루지만, 스크린샷의 내용에서 확인할 수 있습니다.

Gone Brain-dead on Linux

지금까지 다루어본 SSD 중 최악이었습니다. 성능이 아닌, 호환성 부분에서 말이죠.

우선, 일반적으로 Linux의 부팅을 시도해 보면 nvme list 명령어에 올라오지 않습니다. dmesg 명령을 이용하면 장치가 준비되지 않았다는 메시지를 확인할 수 있고요.

이는 제 테스트 플랫폼인 Rocky Linux 10(6.12.0-55.12.1.el10_0)에서 재현할 수 있는 문제였으며, 다른 사람들에게서도 유사한 오류가 보고된 것을 확인할 수 있었습니다.

해당 게시물에서는 자신이 발견한 특징을 알려주고 있었으나, 제겐 영어 울렁증이 있습니다.

번역기는 좋은 문명이네요. 아무튼, Windows의 은혜를 입어야 Linux에서 작동하는 것으로 예상됩니다.

Windows 맛을 잠깐 보여주니 Linux에서도 정상적으로 인식되고 잘 작동합니다. HMB로 64MiB가 할당된 것도 확인할 수 있었습니다.

하지만, 두통은 여기서 끝나지 않고, 드라이브의 연결이 갑작스럽게 중단되는 문제가 발생합니다. 아마 SLC Cache 회복 테스트를 진행하며 nvme format명령어를 사용할 때 드라이브가 떨어지는 것 같은데, 직접 명령어를 날려보니 떨어지지 않습니다.

싸우자는 거냐.

아무튼, 이러한 이유로 재부팅을 약 5번 정도 진행하고 나서야 벤치마크를 종료할 수 있었습니다.

자세하게 읽어보진 않았지만, 동일한 컨트롤러를 채용한 다른 SSD도 Linux에서의 작동에 문제가 있는 것을 보고하는 사례를 확인할 수 있었습니다. 아무리 봐도 꽃게 문제 같지 않나요?

[2025.12.31 추가]

커뮤니티에 배포했던 리뷰에 user_1038534님께서 댓글을 남겨주셨습니다. Ubuntu 24.04를 기반으로 하는 Linux Mint를 사용하시는데, C910에서 저와 같은 오류는 없으셨던 것 같습니다.

다시 테스트할만한 기회가 주어진다면 여러 커널 버전과 종류에서 인식 여부를 다시 체크하도록 하겠습니다. 플랫폼도 바꿔가며 말이죠.

SW Report

CrystalDiskInfo의 보고값입니다. 총 쓰기량이 드라이브의 용량도 되지 않는 깨끗한 물건이네요.

smartmontools와 NVMe-CLI의 id-ctrl 결과는 GitHub에 첨부하도록 하겠습니다.

DUT Summary

벤치마크를 진행할 DUT에 관한 요약입니다.

ESSENCORE K04TBM2SP0-C91 [KLEVV CRAS C910 4TB]
Link	PCIe 4.0 x4	NVMe Version	NVMe 1.4
Firmware	VF101C59	LBA Size	512B
Controller	Realtek RTS5772	Warning Temp	100 °C
Storage Media	SK hynix V6 TLC	Critical Temp	110 °C
Power State	Maximum Power	Entry Latency	Exit Latency
PS0	8.00 W	0 μs	0 μs
PS1	5.00 W	0 μs	0 μs
PS2	4.00 W	0 μs	0 μs
PS3	0.1000 W	5000 μs	10000 μs
PS4	0.0050 W	17000 μs	60000 μs

하위 Power State의 값들이 조금 높아 보이는 느낌입니다. 그렇지만, 무엇보다 눈에 띄는 것은 상당히 높게 잡힌 허용 온도네요. Warning 100 °C, Critical 110 °C로, 여태껏 제가 보아왔던 SSD들에 비하면 부담스러울 정도로 높습니다.

Comparison Device

비교군은 아래와 같습니다.

Name	Why?
P3 Plus 2TB [P9CR40D]	데이터를 가지고 있는 유일한 DRAMless NVMe SSD.
PM981a 256GB [3L1QEXH7]	구형의 DRAM TLC SSD.
970 PRO 1TB [1B2QEXP7]	구형 플래그십 제품, DRAM MLC SSD.

cSSD에 대응하는 데이터가 부족해서 어떻게든 끌어모은 결과입니다. 그렇다고 PM9E1 같은 최신 플래그십을 들고오기엔 적합하지 않으니까요.

Test Platform

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

HW 사양에 대해서는 상단 우측의 fastfetch를 통해서 확인할 수 있지만, 다시 언급하자면, AMD의 9600X를 사용하고 있습니다. DUT는 5.0 x16 연결이 가능한 PEG 슬롯에 장착됩니다.

자세한 벤치마크 방법론에 대해서는 이전에 작성한 Refresh Benchmark를 참고해 주시길 바랍니다.

cSSD Benchmarking

start /wait Rundll32.exe advapi32.dll/ProcessIdleTasks

Windows에서는 위의 명령어를 실행하고 15분 뒤를 IDLE 상태로 정의해 벤치마크를 진행합니다. 각 벤치마크 사이에는 5분의 휴식 시간이 부여되며, Purge는 Linux에서 nvme format 명령어를 통해 수행했습니다.

CrystalDiskMark 9.0.1

Windows에서 인식하는 용량은 3726GiB임을 확인할 수 있으며, 스펙시트의 SEQ R/W 5200/4800 MB/s와 RND R/W 540k/600k IOPS = 2212/2458 MB/s를 모두 만족하는 모습입니다.

SEQ는 대체로 가장 좋은 모습을 보였지만, RND는 P3 Plus에 밀리며 970 PRO와 비슷한 모습을 보여주었습니다. QD1에서는 가장 우수한 모습이었습니다.

3DMark Storage Benchmark

3DMark에서는 0%와 75%에서 각각 2561점과 2544점으로, 유의미한 차이가 보이지 않았습니다. 좋다면 좋다고 할 수 있겠으나, 비어 있는 상태의 P3 Plus 2TB에 밀리는 부분은 아쉽습니다.

SPECworkstation 4.0

SPECworkstation에서는 가장 나쁜 모습을 보였습니다. 여기서도 0%에서는 0.49, 75%에서는 0.48이라는 값이 나와 큰 변동이 없었습니다. 4TB 라는 큰 용량과 대용량의 SLC Cache에 의해 생기는 모습으로 보입니다.

개별 워크로드에서는 0.49라는 결과 속에 숨겨진 의미를 보여줍니다. 예를 들어, proddev 워크로드에선 심각할 정도로 뒤처지는 모습을 보였지만, namd 워크로드에선 조금 선방하는 모습을 보였죠.

아쉬운 점은 비어있는 상태의 DUT지만, 75%가 채워진 P3 Plus에 밀리는 워크로드가 많습니다. 이 부분은 많은 사람들의 직관과는 다른 결과가 아닐지 생각합니다. 특히, 제가 가진 P3 Plus 2TB의 데이터는 QLC 제품인 부분에서 말이죠.

Fill Drive

나래온 더티테스트와 비슷한 벤치마크입니다. FOB상태로 시작하여, SEQ 128k QD256으로 드라이브 전체를 2회 채우며, 0.1s 단위로 값을 측정합니다. 1회차와 2회차 사이의 휴식은 충분히 부여됩니다.

첫 번째 채우기입니다. 전체 평균 속도는 587MB/s이며, 최대 1.5TB에 달하는 SLC Cache 용량을 보여줍니다. 다만, 이러한 상황을 상정하지 않은 것인지 모르겠으나, SLC Cache 이후의 속도가 안정되지 않는 모습을 보입니다. 무식하게 SLC만을 추구하려는 것 같진 않지만, 그닥 좋은 모습은 아닙니다.

우선, SLC Cache 부분입니다. 성능은 꽤 일관성이 보이며, 평균적으로 4871.47MB/s의 속도를 보였으며, 밀집된 부분은 4870MB/s의 속도를 확인할 수 있었습니다.

그럼, 그 뒤를 확인해 봅시다. X축을 300초 ~ 6811초로 하였으며, Y축은 보기 쉽도록 -200MB/s ~ 1000MB/s로 제한했습니다. 일부 잘려버린 포인트를 포함해 이 영역의 평균 속도는 390MB/s로 측정되었으며, 최빈값은 385MB/s 였습니다. 빨간 선을 참고해 주세요.

SLC Cache 외부에서는 보통 직접적으로 TLC/QLC에 작성하는 속도와 SLC의 내용물을 빼내어 TLC/QLC에 작성하는 속도 등 여러 단계의 속도가 관찰되는 경향이 있습니다만, 이렇게 불규칙하게 데이터가 분포하는 것은 어떻게 해석해야 할지 모르겠네요. 당황스럽습니다.

해당 영역의 히스토그램(bins=1000)도 함께 제시합니다. SLC Cache 이후의 데이터로만 이루어져 있습니다. 조금 전에는 제대로 확인할 수 없었지만, 약 290MB/s에 대응하는 값도 꽤 빈번하게 나온 것으로 보입니다.

그럼, 휴식을 부여한 뒤, 두 번째 쓰기 작업을 시작합시다. GC의 낮은 난도가 비교적 일관성 있는 모습을 보여줄 수도 있다고 기대했지만, 그런 일은 일어나지 않았습니다.

비교적 만족스러운 것은 최소 SLC Cache의 크기가 약 65GB인 것과 비교적 유의미하게 여러 단계의 속도를 확인할 수 있었다는 부분입니다.

궁금하신 분들을 위해 시간축 그래프를 다시 준비했습니다. 여러 단계의 속도가 보이시나요? 일관성은 떨어지지만, 1000초와 6000초 정도를 기준으로 약간의 속도가 달라지는 것을 확인할 수 있습니다.

위와 동일하게 상한을 1000MB/s로 잡고 bins=1000로 그려진 히스토그램입니다. 시간에 따라 달라지는 추세는 확인할 수 있었지만, 겹치는 부분이 발생하여 제대로 된 분석을 시행하기엔 난도가 있어 보이네요. 이쯤에서 마무리 하겠습니다. 참고로, 최빈값은 379MB/s였습니다.

첫 번째와 두 번째의 Fill Drive에 대한 전체 평균값은 위와 같습니다. PM981a 256GB와 상당히 비슷합니다. 용량이 더 큰 만큼 전체 드라이브를 2회 채우는 데는 약 16배의 시간이 걸리겠지만요.

자주 이야기하지만, 이 부분은 일반소비자용 워크로드가 아니니 크게 신경 쓸 필요는 없습니다.

첫 번째 Fill Drive에 대한 하위 1% 속도입니다. 여긴 나름대로 의미 있는 값일지도 모르겠습니다. 썩어도 TLC인걸까요, P3 Plus와 비교하면 명백하게 상위에 있는 모습입니다.

Sync Performance

자체적인 Pre-Conditioning 이후, 해당 영역에 한해서 측정됩니다. 쓰기량은 총 500MiB이며, 최대 소모 시간은 2분으로 제한합니다. sync=1 옵션을 활용했습니다.

26.45MB/s라는 속도를 보여주었습니다.

Low QD Performance by RW Ratio

이전과 마찬가지로 Pre-Conditioning 이후에 측정하며, Burst 성능을 측정하기 위해서 각 단계에서 가해지는 I/O의 양은 GB 단위가 되지 않습니다. 다시 말해, 매우 가벼운 부하입니다. 전체 용량의 75%는 이미 채워져 있지만요.

느긋하게 확장되는 모습을 보여줍니다.

Weighted Graph

QD1 80%, QD2 15%, QD4 5%로 가중치를 부여해 보기 쉽게 나타냅니다.

100% 쓰기에선 가장 나쁜 모습을 보여주지만, 그 외의 비율에서는 970 PRO와 상당히 유사한 모습을 보여주고 있습니다.

Performance by Active Range

접근하는 범위를 2배로 늘려가며 RND 4k QD256의 읽기를 가합니다. I/O 지역성을 낮추어 L2P Table에 대한 Cache miss를 발생시키는 것이 목적입니다.
일반적인 DRAM:NAND = 1:1000의 비율을 따르는 SSD들은 성능 변화가 거의 없지만, 이 비율을 따르지 않고 단순하게 Caching을 진행했거나 DRAMless 구조를 채용했다면, 드라이브의 넓은 영역에 걸쳐 발생하는 I/O에 대해 성능이 하락합니다.

C910 4TB는 DRAMless SSD이지만, HMB가 활성화되어 있습니다. 이 용량은 64MiB가 보고되었는데... 속도가 일관되어 있습니다.
전체 영역에 대응할 수 있는 DRAM SSD의 특징 중 하나도 이 그래프에서 속도가 일관되어 있다는 점이죠. 그럼, C910은 DRAMless이지만, DRAM SSD의 성능을 보여주는 것일까요?

그럴 리가 없죠. DRAM SSD라면 일관된 고성능을 보여주었을 것이지만, C910은 일관된 저성능을 보여주고 있습니다. P3 Plus와 비교하면 그 차이가 드러납니다.

HMB가 활성화된 것은 확인했는데, 제대로 사용하지 못하는 것일까요? 하필 속도도 500MB/s 이하라 블라인드 테스트를 진행하면 870 EVO로 오해하는 것이 아닐까 싶습니다. 생각해 보니 Fill Drive의 평균 속도까지 가져오면 정말 870 EVO라고 해도 속지 않을까요?

지금으로써는 Linux에서 발생하는 문제라고 생각됩니다. 생각해보면 위에서 CDM으로 진행한 1GiB에 대한 랜덤 읽기 성능은 스펙대로 잘 나왔거든요.

Windows만 편애하는 것 같네요.

SLC Cache Reclaim

SLC Cache의 회복에 대해서 알아보기 위해 설계되었습니다. Purge를 수행하고, User Capacity의 50%를 SEQ 128k QD256로 채운 뒤, 잠깐의 휴식을 취합니다. 이후, SEQ 128k QD256 쓰기를 1분간 진행합니다.
이 휴식 시간을 늘리며 테스트를 7회 진행합니다. 그래프들은 휴식 이후 1분간의 I/O에 대한 결과입니다.

최대 쓰기량은 2분의 휴식이 부여된 후, 196GB가 발생했습니다. 바로 아래의 그래프를 보시죠.

그래프의 기울기가 속도에 해당합니다. 30초의 휴식 시간부터 SLC Cache의 복구가 진행된 것을 볼 수 있고, 그 미만에서는 초기에 SLC Cache의 혜택을 받지 못하는 것을 확인할 수 있습니다.

그럼, 30초부터 살펴봅시다. 확실하게 초기 SLC Cache 용량이 회복된 것을 확인할 수 있습니다.

나머지도 살펴보도록 하죠. Y축의 최댓값이 2000MB/s 이하라는 것이 위 그래프와의 차이점입니다. 사실상 아래쪽에서 놀고 있는 모습이죠.

eSSD Benchmarking

Boot Workload (OCP BootBench)

eSSD 벤치마크는 Steady State를 측정하는 것이 목표입니다. 하지만, 고성능의 cSSD를 제외하면 Steady State에 진입하는 시간 자체가 굉장히 오래 걸리며, 진입하지 못할 수도 있습니다.

따라서, 비교적 가벼운 OCP BootBench를 통해 eSSD 테스트의 수행 여부를 결정합니다. 하이퍼스케일에서 Boot SSD를 위해 정의된 테스트이며, 동기 쓰기와 TRIM, 읽기가 동시에 진행됩니다. 결과의 IOPS는 읽기이며, 60k IOPS를 넘겨야 통과입니다. 물론, 지정된 TRIM, 쓰기 속도를 달성하지 못해 테스트 자체가 실패할 수 있습니다.

C910 4TB는 P3 Plus 2TB에 이어서 테스트에 실패했습니다. DRAMless SSD들이 힘을 못 쓰고 있군요. 약간은 무거운 워크로드이다 보니 어쩔 수 없기도 합니다.

아쉽지만 eSSD 벤치마크는 여기서 마무리합니다.

Closing

솔직히 C910엔 굉장히 실망했습니다. 첫 번째는 호환성 문제, 두 번째는 SLC Cache 외부의 모습입니다. 대용량의 SLC Cache를 채용하는 것이 현 cSSD의 트렌드이며, 평균적인 SSD의 용량이 늘어난 현재, 이는 확실하게 유효한 전략이라는 것은 잘 알고 있습니다. 많은 일반 소비자 워크로드는 쓰기보단 읽기에 집중되어 있으며, I/O의 양도 비교적 적고 유휴시간이 길기 때문입니다.

그렇다고 해서 대용량 SLC Cache만 가져다 놓으면 될 것이라는 마인드는 보기 좋지 않습니다. 개인적으로는 DRAMless 기술 자체를 꽤 고평가하는 편인데, DRAMless SSD의 평가를 떨어뜨리는 원인 중 하나를 직접 경험한 기분입니다. HMB의 작동 여부에 대해서는 의문이 들지만요.

C910 4TB는 높은 확률로 RTS5772의 기본 형태를 채용한 것으로 생각합니다. 펌웨어도 마찬가지고요. 이에, C910에 대한 비판은 곧 동일 컨트롤러와 펌웨어를 사용하는 여러 SSD에 적용될 것으로 생각되는데, 앞으로 더 경험하고 싶진 않네요. Realtek 컨트롤러는 이전에 중국산 SSD를 리뷰하면서 처음 만났는데, 이번 NVMe SSD로 인상 개선은커녕, 악화가 되어가고 있습니다.
언젠가 다시 만나게 된다면, 제 인상을 좋은 의미로 깨주었으면 하는데, 과연 어떨지...

다음 리뷰는 내년부터 일주일 간격으로 업로드 될 것 같습니다. 주제들이 궁금하시면, 이 게시물을 참고하시면 좋을 것 같네요.

읽어주셔서 감사합니다.

C910 4TB 제품을 빌려주신 지인분께 이 글로 감사 인사를 전합니다. P3 Plus 2TB를 빌려주신 분인데, 다른 리뷰들 때문에 조금 늦어버렸네요.