O que realmente acontece dentro de um SSD durante uma operação de gravação

Why Real Write Behavior Looks Nothing Like Benchmarks

When people talk about SSD performance, they usually talk about speed numbers.
But inside an SSD, a write operation is not a simple “data in, data stored” process.

In reality, every write passes through multiple internal stages, each of which affects performance, endurance, and long-term stability.

Understanding this internal flow explains:

• why short benchmarks look impressive

• why sustained writes slow down

• and where write amplification actually comes from

---

1. The Real Write Path Inside an SSD

A write operation inside an SSD typically follows this sequence:

Host → Controller → DRAM Cache → NAND Flash

Each step serves a purpose — and each introduces trade-offs.

1️⃣ Host to Controller

The host system (OS or application) sends write commands through SATA or PCIe.
These commands arrive out of order, in small blocks, and often mixed with reads.

The SSD controller’s first job is not writing data —
it is organizing chaos.

---

2️⃣ Controller Logic: Translation and Scheduling

The controller translates logical block addresses (LBAs) into physical NAND locations using the Flash Translation Layer (FTL).

At this stage, the controller:

• groups small random writes

• schedules them across multiple NAND channels

• decides when to erase old blocks

None of this is visible in benchmarks — but it defines real performance.

---

3️⃣ DRAM Cache: The Critical Buffer

Before data reaches NAND, it usually lands in DRAM cache.

This DRAM is used to:

• store mapping tables

• merge small writes into larger chunks

• reduce immediate NAND writes

This is why many SSDs appear extremely fast at first —
you are often writing to DRAM, not NAND.

Once the cache fills or flushes, behavior changes.

---

4️⃣ NAND Flash: The Slow, Permanent Step

NAND flash cannot overwrite data directly.

Each write requires:

1. Reading existing data

2. Modifying it

3. Erasing entire blocks

4. Writing new pages

This is where physical limits appear — and where performance slows down.

---

2. Where Write Amplification Comes From

Write amplification happens when the SSD writes more data internally than the host requested.

Why It Happens

• NAND requires block-level erase

• Small random writes force read–modify–write cycles

• Garbage collection moves valid data repeatedly

A Simple Example

This invisible extra work:

• increases latency

• consumes endurance

• raises internal temperature

Write amplification is not a flaw —
it is a structural reality of flash memory.

---

3. Why Short Benchmarks Look So Good

A maioria dos benchmarks de SSD:

• run for seconds, not hours

• use empty drives

• focus on burst writes

In this phase:

• data fits inside DRAM or SLC cache

• garbage collection is minimal

• NAND is fresh and unfragmented

Resultado:
👉 peak numbers that users rarely see again.

---

4. Why Sustained Writes Behave Completely Differently

During sustained writes:

• DRAM cache fills

• SLC cache converts back to TLC / QLC

• garbage collection becomes active

• NAND erase cycles accumulate

This is when:

• write speed drops sharply

• latency becomes inconsistent

• thermal throttling may appear

Two SSDs with similar benchmark scores can behave very differently here.

---

5. Sustained Write vs Burst Write: A Practical Comparison

This gap explains why:

• criação de conteúdo

• logging systems

• database workloads

often expose weaknesses that benchmarks never show.

---

6. Why This Matters for OEM and System Design

For OEMs, understanding write behavior is critical because:

• failures appear late

• performance degradation is gradual

• instability is workload-dependent

Selecting an SSD based only on peak write speed ignores:

• cache exhaustion behavior

• long-term write amplification

• thermal and power stress

Stable systems are built by matching SSD behavior to real workloads, not benchmark charts.

---

Conclusion: Writing to an SSD Is a Process, Not a Number

An SSD write is not a single action —
it is a pipeline of buffering, translation, scheduling, and physical limitations.

Short benchmarks show what an SSD can do briefly.
Real workloads reveal how it behaves over time.

Understanding this difference is the foundation for:

• correct SSD selection

• realistic performance expectations

• and long-term system stability

At Oreton, SSD validation focuses on sustained behavior, consistency, and workload realism — because how an SSD writes over time matters far more than how fast it writes once.