SSD i Trim Command... Jak to właściwie działa

Cześć!

Znajomy właśnie podesłał mi jeden artykuł tłumaczący dlaczego smartfony i tablety z czasem zwalniają:
http://blog.pclab.pl/mieszko/Dlaczego.m%C3%B3j.smartfon.zamula.si%C4%99.po.pewnym.czasie,312

Bardzo zaskoczył mnie jeden fragment:

[...] Rozwiązaniem tego problemu jest TRIM, czyli komenda, która w momencie jej wywołania, nakazuje wyczyścić nośnik z pozostałości po skasowanych plikach, zanim zaistnieje potrzeba zapisania czegoś nowego w ich miejsce, dzięki czemu nośnik może pracować cały czas z pełną szybkością.
[...]
Jeśli producent sprzętu ustawi flagę discard, to TRIM jest uruchamiany od razu w momencie kasowania pliku, więc dane są usuwane nie tylko „z widoku” użytkownika,__ ale też fizycznie__.

Chodzi o to:
Wiem że na tradycyjnych dyskach twardych, jak kasuję plik, to system zapamiętuje sobie że obszar pamięci zajmowany przez ten plik jest wolny i można go śmiało napisać nowymi danymi.

Znajomy po przeczytaniu artykułu zrozumiał to tak, że "na SSD nie da się nadpisać danych - muszą one zostać wcześniej skasowane".
Przy "pierwszym czytaniu" też to tak zrozumiałem ale stwierdziłem że to kompletna bzdura - jeśli plik ma 2GB to przy jego usuwaniu "kasowano" by te 2GB...? czyli co, wypełniano by je zerami? Zacząłem szukać informacji w internecie ale spotykałem się z podobnym opisem. Pomyślałem dłużej...

Ja rozumiem to tak, że:
W przypadku HDD, system zarządzał gdzie umieścić dane. Adres danych widziany przez OS pokrywał się z fizycznym położeniem danych na dysku (mniej/więcej)?

W przypadku SSD systemowi też wydaje się że zarządza danymi ale w praktyce SSD układa dane wg swojego uznania?
Bez TRIM, gdy usuniemy plik, OS będzie wiedział że dany obszar pamięci jest wolny, ale SSD nie otrzyma tej informacji i nie będzie mógł efektywnie zarządzać pamięcią.
Jeśli natomiast system wyśle do SSD "TRIM Command", kontroler będzie wiedział że te dane można śmiało nadpisywać ALE dane też fizycznie pozostają w komórkach pamięci tak samo jak w HDD.

Czy dobrze to rozumiem?

Chyba dobrze rozumiesz.

Cały problem rozbija się o wear leveling. Pamięć flash ma określoną ilość cykli zapisu, więc kontroler pamięci musi mapować sobie bloki z adresów zewnętrznych na wewnętrzne i przemieszczać bloki danych tak, by zrównoważyć ilość zapisów w poszczególnych strefach pamięci flash.

Bez TRIM kontroler flash nie wie które dane są potrzebne, a które nie i zakłada, że wszystkie są potrzebne. Stąd podczas wear levelingu musi wykonywać więcej kopiowań danych. Jeżeli komendą TRIM oznaczysz pewne bloki danych jako niepotrzebne, to kontroler nie będzie przejmował się zawartością tych bloków.

Szybkość działania kontrolera zależy od ilości wolnego miejsca, które jest wymagane by wear leveling mógł działać. Im więcej wolnego miejsca tym mniej przenoszenia danych jest wymagane by utrzymać zrównoważone ilości zapisów oraz tym łatwiej jest rozproszyć puste bloki na różne, działające równolegle podukłady nośnika SSD. Nie znam się dokładnie, ale nośnik SSD składa się z wielu kości flash i każda działa równolegle, a wydajność całego nośnika jest większa niż pojedynczej kości właśnie dlatego, że działają równolegle i wszystkie naraz mogą obsługiwać żądania. W przypadku gdyby zdarzyło się tak, że wolnych bloków jest mało i wszystkie skupiłyby się na jednej kości flash, a reszty kości byłoby kilkanaście, to podczas wear levelingu wszystkie kopiowania bloków musiałyby być przepychane przez jedną kość, co znacząco spowolniłoby działanie całego nośnika SSD. Im więcej bloków jest oznaczonych jako wolne, tym łatwiej je rozproszyć po kościach flash na tyle, by wear leveling mógł pracować z pełną prędkością.

Co do:

Znajomy po przeczytaniu artykułu zrozumiał to tak, że "na SSD nie da się nadpisać danych - muszą one zostać wcześniej skasowane".

Sposób zapisu na pamięciach flash jest inny niż na dyskach HDD. Na HDD głowica jest w stanie odwrócić dowolny bit pojedynczo. W pamięciach flash nie ma takiej możliwości. Można zrobić dwie rzeczy: albo przestawić dowolne zero na jedynkę (albo odwrotnie, ważne że tylko w jedną stronę zawsze działa takie dowolne przestawianie) albo wyzerować hurtowo cały blok pamięci. Z wear levelingiem i TRIMem ma to niewiele wspólnego, ale za to tłumaczy spadek wydajności dysków SSD przy dużych ilościach małych zmian w plikach. W pamięci flash nie da się tak po prostu nadpisać kilku bajtów w jakimś miejscu. Trzeba skopiować pewien mały blok pamięci (a przed skopiowaniem dokonać zmiany tych kilku bajtów) i powtórnie go zmapować.

Myślę, że jednak nie o to chodziło autorowi cytatu, a jednak o oznaczenie bloków jako nieużywane, a nie fizycznemu zresetowaniu ich zawartości. Chociaż nie wiem dokładnie, nie chce mi się specjalnie zastanawiać co autor miał na myśli :]

Wibowit napisał(a):

Na HDD głowica jest w stanie odwrócić dowolny bit pojedynczo. W pamięciach flash nie ma takiej możliwości. Można zrobić dwie rzeczy: albo przestawić dowolne zero na jedynkę (albo odwrotnie, ważne że tylko w jedną stronę zawsze działa takie dowolne przestawianie) albo wyzerować hurtowo cały blok pamięci.

Przestawić dowolne zero na jedynkę albo jedynkę na zero...? To by się niczym nie różniło od nadpisywania...?

///AAA, dobra łapię. Zależnie od kości pamięci możemy np tylko zamienić 0->1 ale nie 1->0.

Cała zawartość dysku HDD jest stabilna. To znaczy, że „treść” sektorów po skasowanych plikach pozostaje niezmieniona do czasu ich zamazania innymi danymi.

Na SSD polecenie trim nie zeruje danych już teraz natychmiast, ale daje znać kontrolerowi, które bloki nie są aktualnie potrzebne - więc ich zawartość może zostać utracona w każdej chwili na skutek remapowania bloków. Dzięki temu remapowanie może działać skuteczniej, a kontroler nie będzie się przejmował danymi, które dla systemu operacyjnego są już i tak śmieciami.

Na HDD to nie ma znaczenia bo sektorów się nie remapuje w normalnych okolicznościach (tylko w przypadku błędów). Dany sektor można nadmazywać teoretycznie miliony razy, a nie tylko tysiące jak w SSD.