SSDki (jak i inne nośniki wykorzystujące układy Flash-NAND) zużywają się od operacji programowania (zapisu) i kasowania. Zużywają się układy pamięci. Same kontrolery padają wyjątkowo rzadko, a tzw. uszkodzenie kontrolera jest jedynie stosowanym przez serwisy i firmy odzyskujące dane skrótem myślowym. W rzeczywistości to nie kontroler, jako układ elektroniczny, a oprogramowanie układowe jest przyczyną awarii. Dokładniej - elementy oprogramowania układowego zawarte w układach Flash-NAND - bo tam są przechowywane te części firmwaru, jakie często się zmieniają, jak np. logi SMART, listy defektów i tablice warstwy translacji Flash (Flash Translation Layer - FTL - i to własnie to najczęściej się rozsypuje).
Odczyt nie jest destrukcyjny, podobnie, jak i samo podłączenie do zasilania (o ile nic bardzo dziwnego się na zasilaniu nie dzieje), tak więc czas pracy sam w sobie nie ma istotnego znaczenia dla żywotności SSDków - dużo ważniejszy jest sposób eksploatacji. Sam TBW jest parametrem pochodnym od deklarowanej przez producentów liczby cykli P/E (programming/erasing) i wynika z przemnożenia tego parametru przez pojemność nośnika. Możemy odwrócić tę operację i wychodząc od TBW i pojemności nośnika łatwo się przekonać, jak dostajemy coraz gorsze układy. Tak, często SSDki padają przed zużyciem deklarowanego TBW - jest to parametr w pewnym sensie statystyczny i ma chronić producentów przed roszczeniami gwarancyjnymi w przypadku dysków zabijanych dużą liczbą zapisów. Dzięki temu można dać długą gwarancję przy jednoczesnym ograniczeniu jej przez TBW zużywany nie tylko świadomymi operacjami użytkownika, ale też operacjami w tle zarówno na poziomie systemu operacyjnego, jak i oprogramowania układowego. Dlatego argumenty typu "musiałbyś codziennie przez X lat zapisywać Y GB danych" podobają się producentom. Wystarczy jednak zwrócić uwagę, ile z TBW potrafi zeżreć np. większa aktualizacja Windowsa, by zrozumieć, że TBW w rzeczywistości jednak jest istotnym ograniczeniem gwarancji. Jeśli interesuje Cię bardziej szczegółowy opis fizyki przechowywania danych w SSDkach, to jest tu: http://kaleron.pl/awarie-SSD.php
Awarie związane z niemożnością zmiany zawartości nośnika najczęściej wynikają z upośledzenia generatora napięć niezbędnych do tunelowania elektronów do/z bramek pływających tranzystorów podczas programowania/kasowania. W takich sytuacjach urządzenie próbuje wykonywać polecenia, ale ze względu na zbyt niski poziom napięcia, elektrony nie są w stanie pokonać bariery potencjału tworzonej przez izolator bramki i fizycznie nic się nie zmienia. A jeśli nie zmieni się stan fizyczny, nie zmienia się też jego interpretacja logiczna i dane zostają w takim stanie, w jakim były wcześniej.
Usterkę SSDka faktycznie dużo trudniej przewidzieć, niż w przypadku twardzieli. Na pewno niepokojące powinny być spadki wydajności, a tym bardziej - błędy odczytu. Jeśli takie rzeczy się zaczynają dziać, warto zabezpieczyć dane i stracić zaufanie do dysku. Poza tym, pomijając upadki, skala awarii SSD typowo jest daleko większa, niż w przypadku dysków twardych, a też(nawet uwzględniając upadki) proces odzyskiwania danych z SSDków przeważnie jest bardziej złożony, niż w przypadku dysków twardych.
"odświeżanie" ładunków w tranzystorach jest mitem. Błędy bitowe występują, i to w coraz większej skali. Ale "odświeżanie" nie daje gwarancji przepisania strony w 100 % poprawny sposób - po prostu wystąpią inne błędy w innych miejscach, a jednocześnie "odświeżanie" zużywałoby resurs cykli P/E. Takie pomysły były, ale na tyle nie mają sensu, że nie doczekały się potwierdzonej praktycznej implementacji Za korekcję błędów odpowiadają kody ECC (dawniej BCH, teraz coraz częściej LDPC) i procedura read - retry, jakiej działanie możemy obserwować w postaci spadku wydajności przy odczycie. Producenci stosują tez inne metody minimalizowania wpływu błędów i zwiększania szans SSDka na przeżycie okresu gwarancji, ale to duży temat. Może kiedyś znajdę czas, by go bardziej szczegółowo opisać.
"Zapełnienie" SSDka przy włączonej funkcji TRIM wpływa na to, ile bloków faktycznie jest zajętych fizycznym przechowywaniem danych, a ile może być w stanie wolnym (skasowanym) gotowych na przyjęcie nowych informacji. TRIM wpływa i na wydajność dysku SSD i na jego żywotność - bo pozwala ograniczyć liczbę fizycznych operacji kasowania i programowania. Parę słów więcej o TRMie: https://kaleron.edu.pl/TRIM-w-dyskach-SMR-i-SSD.php
Dane przechowywane w SSDkach są przypisane "na sztywno" na logicznym poziomie adresacji - w strukturze katalogów, w adresacji klastrowej i w adresacji LBA. Ale w adresacji fizycznej adresy LBA mogą zmieniać swoje położenie czy to przy okazji zapisu nowej zawartości, czy "w tle", np. wskutek działania algorytmów wyrównywania zużycia. Dlatego jeśli masz jakieś dane wrzucone "na sztywno" do jakiegoś katalogu/klastrów/adresów LBA, te dane mogą zmienić swoje fizyczne położenie zupełnie poza Twoją świadomością.
Zainteresowanym polecam książki Rino Micheloniego, gdzie zagadnienia związane z układami flashowymi są opisane dużo dokładniej i bardziej szczegółowo.