SMART
Pierwsza rzecz, jaka może nam przyjść na myśl, to SMART, czyli Self-Monitoring, Analysis and Reporting Technology. Technologia ta została wprowadzona przez standard ATA-3 w 1996 r. w celu poprawy bezpieczeństwa danych i ograniczenia ryzyka awarii dysków twardych. Opiera się ona o obserwację i rejestrację różnego rodzaju parametrów i zda-rzeń, co w założeniu ma pozwolić na odpowiednio wcześniejsze zauważenie pogarszającego się stanu dysku i jego prewencyjne wycofanie z eksploatacji zanim dojdzie do awarii.
W pewnym stopniu kłopotliwe są pewne niuanse implementacji obsługi SMARTu przez różnych producentów w różnych generacjach modeli dysków, co utrudnia ich interpretację. Jest to związane z pozostawioną producentom dość dużą swobodą w wyborze obsługiwanych parametrów oraz sposobie ich rejestrowania. Z uwagi na zgodność dysków SSD SATA ze standardem ATA, również i w nich zaimplementowano SMART, jednak jego interpretacja jest o wiele trudniejsza, niż w przypadku dysków twardych. Po pierwsze o wiele bardziej we znaki daje się duża dowolność przy implementacji SMART-u.
Jest to problem tym większy, że o ile do pewnej specyfiki kilku producentów dysków twardych można się łatwo przyzwyczaić, to dla licznych marek SSD ukrywających pod swoimi naklejkami produkty różnych rzeczywistych producentów jest to bardzo trudne. Tym bardziej, że każda marka zwykle korzysta z usług kilku podwykonawców, a i podwykonawcy zwykle dostarczają te same nośniki, różniące się wyłącznie wyświetlaną nazwą modelu dla wielu różnych marek i często bez otwarcia obudowy lub użycia odpowiednich programów nie da się stwierdzić, co tak naprawdę kryje się w środku. Drugim problemem jest niedostosowanie SMART-u do specyfiki fizyki zapisu i przechowywania danych w układach NAND-owych.
SMART był rozwijany przede wszystkim z myślą o zastosowaniu w wykorzystujących zapis magnetyczny dyskach twardych. Dlatego wiele parametrów SMART-u dla SSD jest po prostu fikcją zachowaną jedynie ze względu na wymogi zgodności ze standardem ATA. Oczywiście, z czasem pojawiły się też parametry specyficzne dla SSD. Do najważniejszych z nich należą parametry rejestrujące operacje kasowania oraz programowania. Jeśli pamiętamy o tym, że za zużycie układów NAND-owych odpowiadają właśnie te operacje, jasnym stanie się, dlaczego warto zwrócić na nie uwagę i porównać je z deklarowanymi przez producentów resursami operacji kasowania/programowania lub parametrem TBW. Jeśli liczba operacji wykonanych przez nasz nośnik zbliża się do wskazanego przez producenta poziomu granicznego, warto pomyśleć o jego wymianie.
Trzeba przy tym zwracać uwagę na to, w jakich jednostkach nasz SSD podaje zużycie. Najczęściej jest ono podawane w bajtach lub w jednostkach LBA (sektorach liczących 512 B). W razie potrzeby musimy odpowiednio przeliczyć te wartości. Zwracamy także uwagę na parametr 05 – liczbę uszkodzonych (realokowanych) sektorów. Wprawdzie SSD-ki nie mają fizycznych sektorów i nie prowadzą operacji realokacji, ale mają też wewnętrzną listę defektów, gdzie rejestrują uszkodzone bloki i informację o tych uszkodzonych blokach producenci zwykle umieszczają pod tym parametrem. Rosnąca wartość tego parametru jasno wskazuje na daleko posuniętą degradację układów NAND. Natomiast nieistotne dla nas będą parametry związane z liczbą odczy-tów, uruchomień, czy czasu pracy SSD-ka, gdyż te czynniki nie mają istotnego wpływu na jego zużycie i awaryjność.
Skan powierzchni
SSD wprawdzie to nie dysk twardy i nie ma powierzchni magnetycznej, ale dla zachowania zgodności ze standardami i protokołami komunikacyjnymi zachowuje się tak, jakby ją miał. Skanowanie powierzchni dysku polega na wysyłaniu do niego w odpowiedniej kolejności (zazwyczaj liniowo od 0 do końca) żądania odczytu sektorów LBA i mierzeniu czasu wykonania kolejnych poleceń. W odróżnieniu od dysków twardych (zob. Security Magazine 1(22)/2024) w przypadku SSD-ków czas dostępu do poszczególnych fizycznych jednostek alokacji (stron) powinien być identyczny. W praktyce nie zawsze tak jest i to ma dla nas wartość diagnostyczną.
Przy ocenie stanu technicznego SSD-ka najbardziej pomocny będzie wykres szybkości odczytu. Przy jego ocenie musimy pamiętać o funkcji TRIM pozwalającej oszukiwać użytkownika oraz system operacyjny i zwracać wartości 0x00 dla obszarów nieza-alokowanych w strukturach logicznych systemu pli-ków (zob. Security Magazine 5(14)/2023) bez konieczności ich fizycznego przechowywania i odczytywania. W praktyce taka operacja fikcyjnego odczytu danych jest znacznie szybsza od odczytu realnego i podważa nam wiarygodność wyników testów. Dlatego przed przeprowadzeniem testu najlepiej jest maksymalnie wypełnić SSDka jakimiś plikami, nawet takimi, jakie usuniemy zaraz po zakończeniu testów.
Im szybciej i stabilniej uda się odczytać zawartość SSD-ka, w tym lepszym on jest stanie. Nie musimy się martwić niewielkimi odchyleniami szybkości odczytu, ale jeśli wykres zawiera bardzo duże amplitudy i bardzo wyraźne spadki prędkości odczytu, jest to już powodem do niepokoju. Takie spadki odczytu oznaczają, że strony zawierające wolno odczytywane sektory czytają się niestabilnie i zawierają dużo błędów bitowych. Dla ich poprawnego odczytu koniecznych jest wiele prób i uruchomienie procedury „read-retry”, co zajmuje czas.
„Read-retry” jest procedurą pozwalającą na uratowanie możliwości odczytania stron zawierających zbyt dużo błędów bitowych, by mogły być skorygowane kodami ECC. Podczas odczytu porównujemy napięcia pomiędzy źródłem, a drenem tranzystora z pewnymi napięciami odniesienia i w zależności od tego, czy są one wyższe, czy niższe od progu, przypisujemy im określone wartości logiczne.
Procedura „read-retry” pozwala nam na delikatne obniżanie lub podnoszenie progowych napięć odniesienia, co w przypadku zaprogramowania (przeładowania bramek pływających nadmierną w stosunku do zakładanej liczbą elektronów) lub niedoporogramowania (umieszczenia w bramkach pływających zbyt małej liczby elektronów) pozwala za którymś podejściem odczytać zawartość strony z na tyle małą liczbą błędów bitowych, by była ona możliwa do skorygowania kodami korekcyjnymi.
W czasie testu mogą też wystąpić błędy odczytu. Zazwyczaj są to krótkie sekwencje błędów sumy kontrolnej (UNC) wskazujące na wystąpienie stron, w jakich liczba błędów bitowych przekracza możliwości naprawy zawartości przy pomocy kodu korekcji. Wystąpienie takich błędów jest bezwzględnym powodem dla wycofania SSDka z eksploatacji. W odróżnieniu od nośników magnetycznych, w nośnikach półprzewodnikowych nie ma nadziei na poprawę ich stanu przez nadpisanie zużytych i uszkodzonych jednostek alokacji. Operacje kasowania i programowania jedynie pogłębią degradację układów.
Niestabilna praca systemu operacyjnego
Czasami pierwszym sygnałem wskazującym, że dni naszego SSD-ka są policzone są problemy z systemem operacyjnym. Zawieszanie, resety, niebieskie ekrany, nietypowo długie ładowanie, czy wręcz brak możliwości wystartowania systemu operacyjnego mogą mieć podłoże sprzętowe. W przypadku SSD-ków tym bardziej nie należy tego ryzyka lekceważyć, że w odróżnieniu od dysków twardych, zazwyczaj umierają one śmiercią gwałtowną, a opóźnienie reakcji może skutkować bolesną utratą danych.
Tak samo sygnałem, że z SSDkiem dzieje się coś złego mogą być problemy z jego detekcją przez BIOS. Jeśli BIOS nie rozpoznaje SSDka lub rozpoznaje go w nieprawidłowy sposób, najprawdopodobniej już doszło do awarii. Dlatego w przypadku, jeśli wystąpią problemy tego typu i zdarzy się, że za którymś razem SSD zostanie rozpoznany poprawnie, w żadnym wypadku nie można uznać, że problem sam się rozwiązał. W takiej sytuacji trzeba jak najszybciej przystąpić do zabezpieczenia danych, bo drugiej szansy może nie być.
Podsumowanie
Wskazane wyżej sposoby oceny stanu i przewidywania dalszych losów SSDków są obciążone dużą niepewnością i wysoce zawodne. Typowo awarie SSDków występują nagle, kiedy oprogramowanie układowe przestaje sobie radzić z obsługą błędów, zazwyczaj w sytuacjach wykonywania dużej liczby zapisów w krótkim czasie. Często np. w czasie aktualizacji systemu operacyjnego, co stało się podstawą przekonania, że to właśnie aktualizacja Windowsa może uszkodzić SSD. Przy czym w rzeczywistości do uszkodzenia prowadzi nie tyle aktualizacja sama w sobie, co niezbędne dla jej przeprowadzenia zapisy w powiązaniu z wcześniejszym zużyciem układów.
