Serwis OtakoOdzysk danych SSDFTL — Flash Translation Layer
Tech / Architektura SSD FTL · Translator

FTL w dyskach SSD —
czym jest Flash Translation Layer

Uszkodzenie FTL może sprawić że dysk SSD pokazuje 0 GB, znika z BIOS albo zgłasza błędny model — mimo że dane nadal fizycznie są w pamięciach NAND. To jedna z najczęstszych przyczyn awarii SSD i jedna z najczęstszych rzeczy które naprawiam w laboratorium.

Czym jest FTL

Flash Translation Layer (FTL) — po polsku zwany często translatorem — to warstwa firmware wbudowana w kontroler dysku SSD. Jej zadanie: tłumaczyć adresy logiczne (LBA) widoczne przez system operacyjny na fizyczne lokalizacje zapisu w kościach NAND flash.

Dla systemu operacyjnego SSD wygląda jak zwykły dysk blokowy z liniowymi adresami sektorów — dokładnie jak HDD. FTL jest warstwą abstrakcji która sprawia że to działa, ukrywając wszystkie specyfiki NAND przed systemem.

Translacja adresów LBA → NAND
System operacyjny
widzi LBA 0, 1, 2... N — liniowe adresy sektorów
FTL / Translator
LBA 12345 → die 2 / plane 0 / blok 47 / strona 12 — dynamiczna mapa przechowywana w DRAM lub NAND
NAND Flash
fizyczne kości pamięci — bloki, strony, komórki TLC/QLC/MLC

Kluczowe: to mapowanie jest dynamiczne. Każdy zapis pod ten sam LBA trafi fizycznie w inne miejsce — FTL zawsze alokuje nową wolną stronę i aktualizuje mapę. Stara strona zostaje oznaczona jako invalid i czeka na garbage collection. W HDD sektor 1000 jest zawsze w tym samym miejscu na talerzu. W SSD LBA 1000 może być dziś w bloku 47, jutro w bloku 312.

Dlaczego SSD tego potrzebuje

NAND flash ma fundamentalne ograniczenie: nie można nadpisywać danych w miejscu. Żeby zapisać nowe dane w bloku który już coś zawiera, trzeba najpierw skasować cały blok. A blok to duża jednostka — od kilkuset KB do kilku MB (128–512 stron).

Gdyby system pisał bezpośrednio do NAND jak do HDD, każdy zapis wymagałby: odczytania całego bloku → zmodyfikowania jednej strony w RAM → skasowania bloku → zapisania z powrotem. Absurdalnie wolne i niszczące komórki.

FTL rozwiązuje to przez out-of-place writes — nowe dane zawsze trafiają do wolnej strony, nigdy nie nadpisując istniejących. Dzięki temu zapis jest szybki. GC sprząta po sobie w tle.

Co robi FTL poza translacją

Wear Leveling

Każda komórka NAND wytrzymuje ograniczoną liczbę cykli zapisu/kasowania — 300 do kilku tysięcy zależnie od typu (QLC, TLC, MLC). FTL pilnuje żeby nie zapisywać w kółko w te same bloki — rozkłada zapisy równomiernie po całym dysku.

Garbage Collection

Z każdym nadpisaniem rośnie liczba invalid stron. GC wybiera blok z dużą ich ilością, kopiuje valid strony w nowe miejsce, aktualizuje mapę i kasuje stary blok. GC działa w tle i generuje write amplification.

Over-provisioning i Bad Block Management

FTL rezerwuje część pojemności NAND niewidoczną dla użytkownika (7–28%) jako bufor dla GC i wear levelingu. Śledzi uszkodzone bloki i je omija.

DRAM vs DRAM-less — gdzie jest mapa FTL Dyski z buforem DRAM trzymają całą tablicę L2P w szybkiej pamięci i zapisują ją do NAND periodycznie. Dyski DRAM-less (Phison PS3111, wiele budzetowych) trzymają mape bezposrednio w NAND i cachuja tylko fragment w SRAM kontrolera. Stąd wolniejsze losowe odczyty — FTL musi najpierw odczytac fragment mapy z NAND.

Uszkodzony FTL nie oznacza utraty danych

To jest najważniejsza informacja praktyczna z tego artykułu.

Mapa FTL i dane użytkownika to dwie oddzielne rzeczy fizycznie w NAND. Gdy FTL ulega uszkodzeniu — kontroler traci mapę, nie dane. Dla systemu operacyjnego dysk wygląda jak pusty, uszkodzony albo niewidoczny. Ale dane fizycznie są w kościach NAND, w stronach gdzie zostały ostatnio zapisane.

Odbudowa FTL przez laboratorium to odtworzenie mapy — nie odtwarzanie samych danych. Dane już tam są, trzeba je tylko znowu "zobaczyć".

Objawy uszkodzonego FTL — tabela

Objaw Co sie stalo z FTL Dane w NAND? Program recovery pomoze?
SSD pokazuje 0 GB FTL/firmware nie wystartował, mapa nieosiągalna Tak Nie
Dysk znika z BIOS Kontroler nie inicjalizuje firmware przy starcie Tak Nie
SATAFIRM S11 w BIOS Tryb awaryjny kontrolera Phison — FTL load failure Tak Nie
System pyta o inicjalizację Brak poprawnej translacji — dysk wyglada jak nowy Tak — nie inicjalizuj Nie
Dysk widoczny jako RAW Częściowa korupcja mapy — część LBA wskazuje źle Czesc tak Zależy
NVMe znika podczas pracy FTL crash w trakcie operacji — najczęsciej po zaniku zasilania Tak Nie
Część plików uszkodzona Częściowa korupcja mapy lub degradacja NAND Czesc Zależy

Jak laboratorium odbudowuje FTL

Recuva, Disk Drill, TestDisk — pracują na poziomie logicznym. Potrzebują działającego FTL żeby w ogóle zobaczyć dane. Gdy FTL jest uszkodzony — te narzędzia nic nie zrobią.

PC-3000 SSD używa vendor-specific commands (VSC) — niskopoziomowych poleceń specyficznych dla danej rodziny kontrolerów. Procedura odbudowy FTL:

1
Uruchomienie kontrolera w trybie technologicznym — z pominięciem uszkodzonego firmware przez VSC lub sprzętowe wymuszenie (pin short na kontrolerze)
2
Odczyt konfiguracji NAND — identyfikacja topologii: liczba die, plane, bloki, typ pamięci, interleaving
3
Skanowanie obszarów serwisowych — szukanie fragmentów mapy L2P, checkpointów, migawek translatora zapisanych przez firmware
4
Odczyt metadanych stron NAND — każda strona zawiera LBA stamp i numer sekwencyjny. Sortowanie po sekwencji — najnowsza wersja danego LBA wygrywa
5
Odbudowa tablicy L2P — rekonstrukcja mapy bez zapisywania czegokolwiek na oryginalnym dysku
6
Imaging — obraz sektor po sektorze na niezależny nośnik. Oryginał przez cały czas w trybie tylko do odczytu

Przykład z realnej diagnozy NVMe SSD z uszkodzonym FTL:

Controller     : SM2263XT
Firmware mode  : ROM
Safe Mode      : Yes
Logical access : No
Physical access: No

Translator chunks found: Yes
Saved file     : Translator_SM2263XT_001.bin

Rebuilding L2P table...
Valid pages found: 487,293 / 524,288
L2P reconstruction: OK
Logical image size: 1,000,204 MB

Fragment z realnej diagnozy PC-3000 SSD — kontroler odpowiadał w trybie serwisowym (firmware ROM, safe mode), bez dostępu logicznego. Odbudowa translatora przywróciła dostęp do danych.

Statystycznie — większość SSD które trafiają do laboratorium ma problem właśnie w obszarze FTL lub obszaru serwisowego NAND. Dlatego każde uruchomienie uszkodzonego dysku, każda próba naprawy MPToolem czy flashowania firmware to ryzyko. Kontroler przy starcie może próbować "naprawić" uszkodzoną mapę zapisując nad nią — i zniszczyć jedyne fragmenty które pozwoliłyby na rekonstrukcję.

FTL a szyfrowanie AES

Nowoczesne dyski NVMe (Samsung, WD, Maxio MAP1602, wiele innych) mają sprzętowe szyfrowanie AES-256 zawsze włączone. Klucz (MEK) jest w kontrolerze.

Przy uszkodzonym FTL ale sprawnym kontrolerze — odczyt przez VSC działa, bo kontroler deszyfruje dane na bieżąco. Przy fizycznie uszkodzonej elektronice kontrolera — chip-off NAND da tylko zaszyfrowane dane bez szansy na odczyt. Dlatego przy NVMe z AES-256 priorytetem jest naprawa elektroniki, nie obejście kontrolera.

Często zadawane pytania

Prawie na pewno nie. Zanik zasilania w trakcie operacji zapisu lub GC to klasyczna przyczyna uszkodzenia FTL. Dane fizycznie są w NAND. Kontroler nie może załadować spójnej mapy i wchodzi w tryb awaryjny z 0 GB. Odbudowa FTL przez PC-3000 SSD ma wysoką skuteczność w takich przypadkach — pod warunkiem że dysk nie był potem wielokrotnie uruchamiany.
Recuva i podobne narzędzia operują na poziomie logicznym — odczytują system plików przez normalny interfejs dysku. Gdy FTL jest uszkodzony, dysk dla systemu operacyjnego ma 0 bajtów — nie ma skąd czytać. Te programy nie mają dostępu do surowych kości NAND ani do vendor-specific commands. Potrzebne jest laboratorium z PC-3000 SSD lub odpowiednikiem.
Każdy SSD rezerwuje fragment pojemności NAND jako "obszar serwisowy" (Service Area, SA) — niewidoczny dla użytkownika. Tam jest przechowywany firmware kontrolera, tablica mapowań L2P, listy złych bloków, konfiguracja NAND i inne metadane. Gdy komórki w tym obszarze się zużywają lub ulegają uszkodzeniu, kontroler nie może załadować własnego oprogramowania i wchodzi w tryb awaryjny.
TRIM informuje FTL że dane pod danym LBA mogą być zwolnione. Fizyczne kasowanie następuje dopiero podczas garbage collection. Jeśli dysk miał mało czasu na GC po TRIM — dane mogą być odzyskiwalne. Im dłużej dysk był aktywnie używany po TRIM, tym mniejsze szanse. Mamy osobny artykuł o TRIM i odzysku.

Dysk SSD zniknął lub pokazuje 0 GB?
Opisz mi co się stało.

Model dysku i objawy wystarczą do wstępnej oceny — odpiszę tego samego dnia.

Zadzwoń Wyślij nośnik