Jak pamiętamy z poprzedniego wpisu, w przypadku, kiedy użytkownik usuwa pliki, system operacyjny nie trudni się nadpisywaniem usuniętych danych, a zmienia tylko kilka bitów w odpowiednich tabelach (tzw. flagi). To powoduje, że plik z poziomu systemu operacyjnego staje się niewidoczny. W przypadku dysków SSD takie podejście powodowałoby, że po pewnym czasie dysk zapchałby się niepotrzebnymi danymi i przestał działać. Aby zwolnić zajęte przez „niepotrzebne” pliki komórki pamięci NAND (czyli wykasować te dane na stale), kontroler dysku musi najpierw zidentyfikować pliki, które nie są już potrzebne użytkownikowi.
W tym celu kontroler dysku SSD może zastosować dwie metody:
— zastosować algorytm umożliwiający ciągłe analizowanie struktur kluczowych systemu plików — taki algorytm będzie inny dla każdego systemu plików, tj. NTFS, FAT16/32/64, EXT2/3/4, HFS itd. Aby to robić, kontroler SSD musi mieć dodatkową moc obliczeniową oraz zwiększoną objętość własnego RAM;
— uzyskać informacje o skasowanych plikach od systemu operacyjnego.
Z uwagi na koszty, na rynku dominują urządzenia wykorzystujące te drugie podejście. Nazywa się one TRIM. TRIM jest realizowane jako jedno z poleceń interfejsu, przy pomocy którego system operacyjny komunikuje się z nośnikiem danych, czyli protokołu ATA (ang. Advanced Technology Attachments) – jego współczesną implementacją jest SATA. Za pomocą TRIM system operacyjny może przekazać oprogramowaniu SSD adresy danych, które nie są już potrzebne użytkownikowi. Te dane kontroler SSD wpisuje na listę adresów przeznaczonych do kasowania i rozładowywania (operacja erase). Obe te operacje – kasowanie i rozładowywanie – wykonywane są w tzw. wolnej chwili (idle time) w ramach wspomnianej wcześniej operacji garbage collection.
Czasami prawidłowe działanie funkcji TRIM się zakłóca, bo TRIM wymaga sprawnego współdziałania co najmniej trzech elementów komputera: systemu operacyjnego (TRIM jest nadbudową systemu operacyjnego i musi być w nim prawidłowo zaimplementowany), interfejsu znajdującego się pomiędzy systemem operacyjnym a dyskiem – musi podtrzymywać przekazywanie poleceń TRIM, oraz samego dysku SSD. Błędy w przypadku dowolnego z tych elementów mogą powodować, że TRIM przestanie funkcjonować. Niedziałający lub działający nieprawidłowo TRIM będzie z jednej strony ułatwiał odzyskiwanie usuniętych danych, które będą pozostawały w komórkach pamięci. Z drugiej strony, po jakimś czasie kontroler wykorzystuje wolne miejsce, po czym przed każdą nową operacją zapisywania danych będzie musiał rozładowywać bloki, co istotnie obniża prędkość działania nośnika. W naszej praktyce, kiedy mieliśmy podobne sytuacje, prędkość dysku SSD spadała do około 30 mb/s. Dla porównania, w trybie normalnym jest to 300-400 mb/s.
Wadą i głównym koszmarem, dzięki któremu wiemy o istnieniu TRIM jest to, że od chwili, kiedy dysk SSD otrzymał polecenie TRIM, jego kontroler zaczyna rozładowywać odpowiednie obszary pamięci, co powoduje trwałe usunięcie danych. Kontroler będzie to robił zupełnie niezależnie, w każdej chwili, jak tylko dysk otrzyma zasilanie. Na ten fakt zwrócono uwagę jeszcze w dalekim 2010 r., kiedy to grupa badaczy z australijskiego Murdoch University opisała wpływ mechanizmów działania dysków SSD na możliwości odzyskiwania danych cyfrowych.
W ramach eksperymentu popularny model dysku SSD o pojemności 64 GB porównywano do dysku typu HDD o pojemności 80 GB. Opisano zostało zjawisko tzw. korozji (ang. self-corrosion), tj. samodzielnego, bez polecenia użytkownika czy też systemu operacyjnego, trwałego niszczenia przez kontroler zapisanych na dysku danych cyfrowych.
Badany SSD wykonywał tą operację również w sytuacji, gdy badacze stosowali standardowe metody prewencyjne, zapobiegające uszkodzeniu danych używane przez biegłych policyjnych (utworzenie obrazu dysku, blokada zapisu). Co ciekawe, dysk SSD zaczynał usuwać dane już po upływie 3 minut od momentu włączenia zasilania, a w przeciągu następnych trzech minut potrafił całkowicie usunąć te dane, które były uprzednio oznaczone przez użytkownika jako „niepotrzebne” (wykonywano szybkie formatowanie dysku). W konsekwencji nie udało się odzyskać ani jednego całego pliku. Z 25 000 plików tekstowych, którymi badacze wypełnili dysk SSD, tylko jeden dało się częściowo odzyskać (na 50% jego oryginalnej zawartości). To był najlepszy rezultat. Większość plików zostało uszkodzonych nawet w 82%. „Operację” bezpiecznie „przeżyło” zaledwie 0,03% zapisanych na dysku danych.
Należy zaznaczyć, że badaczy nie zaobserwowali żadnych zmian świadczących o tym, że wykonywany jest algorytm garbage collection – nie było wizualnych czy dźwiękowych ostrzeżeń systemowych, wibracji czy kliknięć, które można byłoby w podobnej sytuacji oczekiwać mając do czynienia z dyskiem typu HDD. Pod tym względem działający dysk SSD niczym się nie różnił od dysku SSD odłączonego od zasilania. Wniosek był taki, że korozja danych cyfrowych w przypadku dysków SSD odbywa się „bezobjawowo”.
Nie każdy jednak dysk SSD zachowuje się tak, jak opisano wyżej. Pamiętajmy, że producenci tych urządzeń, a jest ich ponad 80, mają różne koncepcje, jeśli chodzi o „idealny” SSD. To dotyczy również implementacji polecenia TRIM będącego częścią standardu ATA. Badacze raportują, że niektóre wersje oprogramowania dysków SSD posiadają błędy powodujące to, że dysk nie pozbywa się danych usuniętych przez użytkownika. Nawet jeśli takich błędów nie ma, szybkość przeprowadzenia operacji garbage collection będzie zależała od właściwości fizycznych i ustawień konkretnego SSD.
Powstaje tu także pytanie – co SSD będzie robił z danymi które trafiły do garbage collection, ale nie zostały jeszcze wykasowane przez kontroler? Czy on wciąż będzie je pokazywał pod tymi samymi adresami LBA jak to robi dysk HDD? Czy je ukryje pokazując zamiast same zera? Na szczęście, ten etap funkcjonowania dysku SSD (tzw. Read After Trim) jest także przewidziany w standardzie ATA. Niemniej jednak wybór jednego z trzech proponowanych tu rozwiązań jest indywidualny dla każdego producenta:
1. Non-deterministic TRIM, czyli nie-deterministyczny odczyt po TRIM –SSD może pokazywać dane oryginalne dopóki odpowiednie bloki nie zostaną rozładowane (erase);
2. Deterministic Read After TRIM (DRAT), czyli deterministyczny odczyt po TRIM – przy próbie odczytania sektorów zawierających skasowane dane, SSD zamiast tych danych wyświetla ustawiony przez producenta wzór lub same zera;
3. Deterministic Zeroes After TRIM (DZAT), czyli deterministyczny odczyt zer po TRIM – dane użytkownika wpisane do listy garbage collection nie są pokazywane; zamiast nich pokazywane są same zera i nic więcej.
Pierwsze rozwiązanie czasami znajdziemy w najtańszych modelach dysków SSD wyprodukowanych przez mało znanych producentów. Drugie – deterministyczny odczyt po TRIM – jest najczęściej spotykane. Ostatnie, trzecie, rozwiązanie jest charakterystyczne dla dysków SSD należących do klasy enterprise, tj. tych wykorzystywanych w macierzach RAID.
Użytkownicy systemów operacyjnych na bazie Linux mogą dowiedzieć się, które rozwiązanie jest zastosowane w przypadku ich dysku (SSD) wprowadzając w Terminale polecenie hdparm –I. Na przykład:
$ sudo hdparm -I /dev/sda | grep -i trim
DRAT i DZAT powodują, że dane skasowane przez użytkownika lub system operacyjny robią się niewidoczne z poziomu interfejsu SSD. Niemniej jednak dane te mogą pozostawać przez pewien czas w kostkach pamięci NAND – aż do ich usunięcia (erase) przez kontroler dysku. Czas ten różni się w zależności od modelu dysku. W przypadku sprawnie działającego mechanizmu garbage collection może to być 15 minut lub nawet kilka lat, jeśli z jakiegoś powodu mechanizm ten nie działa. Oczywiście, jeśli odłączyć dysk SSD od zasilania od razu po tym, jak usunięto pliki, czas ten wydłuży się do kolejnego podłączenia zasilania.
Wcześniej jedynym sposobem na odzyskanie danych po uruchomieniu funkcji TRIM był tzw. chip-off – operacja polegająca na wylutowywaniu kostek pamięci i ich późniejszym odczytaniu przy pomocy specjalnego sprzętu. Trudności jednak powstają przy próbie odwrócenia przekształceń (transformacji) danych użytkownika dokonanych przez kontroler przy zapisywaniu tych danych do NAND – to jest przy odbudowywaniu „wirtualnego kontrolera” przy pomocy specjalnego oprogramowania (np. Rusolut). Tego rodzaju modyfikacje są konieczne nie tylko ze względu na dziwną „fizykę” pamięci NAND Flash (o tym pisaliśmy w pierwszej części), ale też, aby zapewnić niezawodność dysku SSD w czasie obowiązywania gwarancji. W związku z tym, odbudowa „wirtualnego kontrolera” dysku SSD jest zadaniem niesamowicie trudnym, czasochłonnym i kosztownym.
Na szczęście, ostatnio pojawiło się inne rozwiązanie – odczyt SSD w trybie factory mode (znanym również jako safe mode). Dostępne ono jest głównie dla posiadaczy programowo-sprzętowego kompleksu odzyskiwania danych PC3000 produkcji rosyjskiej. Więcej na ten temat można dowiedzieć się na oficjalnej stronie AceLab.
Wniosek końcowy brzmi następująco: aby zachować jak najwięcej danych zapisanych na dysku SSD i zwiększyć szanse na odzyskanie danych skasowanych, należy niezwłocznie odłączyć źródło zasilania.
