PDF 原檔：報告_OCP2026_Meta_QLC儲存_20261015_original.pdf
講者公開簡報（OCP 官方 Recorded Content 頁提供下載）。文字以 PyMuPDF 逐頁抽取，
### p<n>為頁碼；圖表內容見原檔。
圖片清單（已驗證 2026-10-19）
| 檔名 | 頁 | 分類 | 親眼所見內容 |
|---|---|---|---|
報告_OCP2026_Meta_QLC儲存_20261015_p4.png |
p4 | 真資料圖 | TLC／QLC／HDD(CMR) 規格對照表：QLC 單碟 2026 最大 122.88–245.76TB（TLC 61.44、HDD 26）、DWPD 0.25–0.6、持續寫入 2.0–3.5GB/s、4K 寫入 25–120K IOPS、4.9–8.2 TB/W、2U 24 碟 2.95PB |
報告_OCP2026_Meta_QLC儲存_20261015_p5.png |
p5 | 真資料圖 | 2U 前面板滿插 24 碟的儲存伺服器機箱實物渲染（含開蓋內部），旁附「A Case for QLC SSDs」部落格與 OCP Endurance Storage System 的 QR code |
報告_OCP2026_Meta_QLC儲存_20261015_p7.png |
p7 | 真資料圖 | QLC 導入初期失效率表（單位簡報未標）：廠商 A 總計 2.9（IO 不可修正＋媒體品質 0.35、PCIe 訊號完整性／掉碟 2.0、治具 0.58）、廠商 B 總計 11.7（媒體 8.8、PCIe 2.7、治具 0.22）、全部 QLC 3.7 |
報告_OCP2026_Meta_QLC儲存_20261015_p14.png |
p14 | 真資料圖 | Drive-managed 與 Host-directed placement 對照流程圖：左側應用不帶提示、SSD 控制器猜測分組、GC 搬移導致 WAF 上升；右側應用標 hot/warm/cold、NVMe 寫入帶 Placement ID（dtype=2）、各進獨立 reclaim unit、host 一次釋放整個 reclaim unit |
原始內容
p1
Joseph Cirnigliaro Meta, Fleet Systems Engineering Vineet Parekh Meta, Fleet Systems Engineering QLC @ Hyperscale STORAGE
p2
A case for QLC SSDs @ Hyperscale
p3
• HDDs have been growing in density, but not performance • QLC enables new workloads that are beyond HDD write throughputs • QLC provides higher rack density and improved power efficiency over TLC SSDs A case for QLC SSDs @ Hyperscale
p4
TLC, QLC & HDD Comparison Specification TLC QLC HDD (CMR) CELL P/E Cycle Endurance (drive) 1,000–3,000 ~1,000 — DWPD (5-year) 1–3 0.25–0.6 — PERF Sequential Read (GB/s) 7–14 7–14 0.30 Sequential Write, sustained (GB/s) 6–10 2.0–3.5 0.30 Random Read, 4K (IOPS) 2.0–3.3M 0.9–2.0M 168 Write IOPS, 4K 280–900K 25–120K 550 SCALE Max Drive Capacity, 2026 (TB) 61.44 122.88–245.76 26 TB per Watt 1.2–3.1 4.9–8.2 2.7–3.1 2U Rack Density (PB @24 drives) 1.47 2.95 0.31 USE CASE Target Workload Write-mixed, latency- sensitive Read-dominant, capacity-dense Sequential / bulk Storage Tier Hot (Performance) Warm (between TLC & HDD) Cold/Mixed
p5
QLC @ Hyperscale Overview STORAGE A Case for QLC SSDs Blog OCP Endurance Storage System
p6
• Supply Chain • Dense Enterprise QLC have high TCO and are increasingly harder to come by • Performance • QLC holds up under large-block, read-dominant traffic, but sustained writes cap at ~3 GB/s and small random writes quickly become the limiting factor • Longevity • Endurance runs low on QLC with DWPD that is sensitive to small random writes • Density raises the stakes over block level error tolerances as these events have the potential of removing hundreds of terabytes worth of capacity Key Bottlenecks of QLC Storage
p7
Early Challenges Onboarding QLC Failure reason Supplier QLC A Supplier QLC B All QLC IO uncorrectable + media quality 0.35 8.8 1.2 PCIe signal integrity / drive missing 2.0 2.7 2.0 Tooling / non-drive signal 0.58 0.22 0.51 Total 2.9 11.7 3.7
p8
Addressing Key Bottlenecks in QLC SSDs
p9
Problem Singular block level failures often result in full drive failures raising annual swap rates Mitigating High TCO and Capacity Constraints
p10
• The paradigm is shifting toward treating localized media failures and transitory errors as expected events to be managed in place • Retiring a mostly healthy device over singular bad blocks wastes scarce capacity • System fault tolerances must allow for added bit errors and still be safe Mitigating High TCO and Unavailable Capacity
p11
Problem Singular block level failures often result in full drive failures driving annual swap rates Solution Enable your storage application to be recoverable and repairable from block level failures Mitigating High TCO and Capacity Constraints
p12
Mitigating High TCO and Unavailable Capacity Self-Healing Block Recovery
p13
Addressing QLC Endurance Problem Inefficient data placement results in WAF of 3-5x causing QLC endurance to be 20% of TLC
p14
Drive-managed placement Application writes carry no placement hints Block layer lifetime information is lost in the stack SSD controller packs writes into open blocks; guesses grouping inside the drive reclaim unit reclaim unit reclaim unit hot warm cold invalidated Garbage collection copies live pages out before erasing WAF ↑ tail latency ↑ endurance ↓ Host-directed placement Application tags each write: hot / warm / cold NVMe write command placement ID rides along (dtype = 2) SSD controller assign each Placement ID to its own reclaim unit inside the drive hot: invalidated warm cold Host deallocates frees a whole reclaim unit at once WAF ↓ steady latency endurance ↑ hot warm cold invalidated
p15
Addressing QLC Endurance Problem Inefficient data placement results in WAF of 3-5x causing QLC endurance to be 20% of TLC Solution Adopt NVMe features to enable application to flexibly place data. Effective DWPD improves from 0.17 to 0.96
p16
Call to Action Flexible Drive Configurations Open to collaborating with storage partners on innovative solutions to allow flexible, dynamic adjustment of SSD specifications to better fit evolving workload demands. Support OCP Data Center NVMe® SSD Specification ●Real-time reporting of NVMe buffer fill level ●GC active/idle state + progress (bytes folded/sec) ●Live WAF reporting ●Host I/Os impacted by GC
p17
Thank You Vineet Parekh - Meta, Fleet Systems Engineering vineetparekh@meta.com Joseph Cirnigliaro - Meta, Fleet Systems Engineering jcirni@meta.com
p18
Appendix
p19
Problem Sustained writes can drop 3–10x after initial SLC or pSLC buffer fills Mitigating QLC Sustained Write Performance
p20
Mitigating QLC Sustained Write Performance
p21
Representative QLC Workload Profile Figure 1. Workload signature of QLC host, note the bursty write pattern in Bytes/s across a 24 QLC drive host
p22
Problem Sustained writes can drop 3–10x after initial SLC or pSLC buffer fills Solution Make the application cache-aware and allocate burst write traffic to prioritized cooled off drives Mitigating QLC Sustained Write Performance
p23
Cache Aware Allocation Burst Write Traffic SSD Cache Aware Allocator READY: cooled off, cache available H1·D2 H2·D1 H2·D3 H3·D2 H3·D3 IN USE: absorbing, cache partly consumed H1·D5 H2·D6 H3·D4 COOLING OFF: consumed, timer running H1·D1 H1·D3 H2·D4 H3·D5 H3·D6 Host-Side Bookkeeping We do not know the drive's internal GC state but we can de- prioritize recently written to drives in the face of new write traffic We can benchmark and classify a given drives cache based on its performance cliff to inform our application logic Host 1 6 drives D1 COOLING 100% consumed D2 READY 0% consumed cooled off D3 COOLING 100% consumed D4 READY 0% consumed cooled off D5 IN USE 60% consumed D6 COOLING 95% consumed Host 2 6 drives D1 READY 0% consumed cooled off D2 COOLING 100% consumed D3 READY 5% consumed cooled off D4 COOLING 100% consumed D5 READY 15% consumed cooled off D6 IN USE 75% consumed Host 3 6 drives D1 READY 5% consumed cooled off D2 READY 0% consumed cooled off D3 READY 0% consumed cooled off D4 IN USE 70% consumed D5 COOLING 100% consumed D6 COOLING 90% consumed READY: cache available IN USE: absorbing COOLING OFF: deprioritized