To wszystko, o czym pisaliśmy w części pierwszej powoduje, że dysk SSD musi mieć pewnego rodzaju „pośrednika” pomiędzy dwoma mechanizmami zapisu i odczytu danych – adresacją logiczną LBA (którą posługuje się system operacyjny) z jednej strony a scalakiem pamięci NAND z drugiej. Ten ostatni, jak już Państwo wiecie z poprzedniego wpisu, może wykonywać tylko trzy rodzaje operacji – read, write oraz erase. Zauważmy, że nie ma wśród nich operacji rewrite, czyli nadpisywania – wynika to z fizycznych ograniczeń tego typu pamięci. Ale tak się składa, że jest to operacja istotna dla funkcjonowania mechanizmu LBA, który bezwarunkowo umożliwia systemowi operacyjnemu zapisywanie/odczytywanie/modyfikację danych w każdym bloku logicznym (de facto sektorze z danymi), który tą adresacją jest objęty – czyli posiada wyrażony liczbą (od 0 do iluś bilionów) adres LBA.
Obraz 1: W programie DMDE widzimy, że każdy sektor z zapisanymi danymi jest oznaczony liczbą porządkową – to akurat jest LBA.
Jak więc organizowana jest współpraca pomiędzy NAND a systemem operacyjnym, jeśli ten drugi musi mieć tą funkcję (modyfikacji/nadpisywania) i nie może bez niej funkcjonować? Niestety mechanizm adresacji LBA był stworzony w czasach, kiedy podstawowym nośnikiem danych były nośniki magnetyczne – dyski HDD oraz taśmy streamerów. W przypadku dysków HDD operacja modyfikacji danych to tylko jeden „przelot” głowicy nad odpowiednimi sektorami, na skutek czego ich zawartość (dotychczasowa) zostaje nadpisana przez nowe dane. Jeśli chodzi zaś o pamięci NAND Flash, to tego rodzaju „zabieg” wymaga szeregu manipulacji. Zajmuje się tym część oprogramowania dysku SSD nosząca nazwę translator (czyli tłumacz).
Warto zwrócić uwagę na to, że dyski typu HDD również mają mechanizm translacji adresów LBA w adresy fizyczne, o czym opowiemy w kolejnych wpisach.
W pamięciach typu NAND jest to tzw. FTL (ang. Flash Translation Layer), który uwzględnia opisaną wyżej specyfikę działania pamięci flash oraz pozwala na przedstawienie urządzenia na poziomie systemu operacyjnego jako tzw. “block device”. Działanie FTL nie jest widoczne z poziomu użytkownika i systemu operacyjnego. Jego prawidłowe funkcjonowanie to zadanie kontrolera pamięci NAND i tylko on o nim wie.
Poniższy przykład obrazuje mechanizm działania FTL w sytuacji, kiedy mamy dwa bloki pamięci NAND oznaczone X i Y.
Obraz 2: Obraz ukazuje działanie operacji “Garbage collection” – jednej z podstawowych funkcji FTL.
Przyjmijmy, że w ramach kroku pierwszego do bloku „X” użytkownik zapisał dane A, B, C oraz D. Dalej użytkownik chce zmodyfikować już zapisane dane, poczynając od A, kończąc na D oraz zapisać obok nowe dane E, F, G oraz H. Z uwagi na to, że raz zapisanych danych zmienić nie można, FTL zapisuje nowe dane A–D do obszaru wolnego bloku „X”. W rezultacie powstają dane A’–D’, a kolejno FTL oznacza wcześniejsze dane A–D jako nieaktualne (ang. invalid). „Nieaktualność” powoduje, że dane stają się niewidoczne dla systemu operacyjnego oraz trafiają do kolejki na kasowanie. Żeby pozbyć się nieaktualnych danych i zwolnić miejsce pod nowe dane, kontroler tworzy kopię danych ważnych (ang. valid) w obszarze wolnym (blok „Y”) – to negatywne dla pamięci NAND zjawisko ma nazwę writeamplification, czyli amplifikacja, poszerzanie zapisu. Dopiero po zabezpieczeniu ważnych danych w bloku „Y” kontroler usuwa wszystkie dane z bloku „X” „rozładowując” (operacja erase) go. Ten ostatni etap jest nazywany „zbieranie śmieci” czyli „garbage collection” – opiszemy go w następnych wpisach. Oczywiście wszystkie opisane manipulacje z danymi są zupełnie nie widoczne z poziomu użytkownika. Stosując FTL kontroler dysku „dba” o to, aby użytkownik, tj. system operacyjny, nie widział niczego poza ładnym ciągiem adresów LBA.
Z powyższego wynika, że FTL, aby działać prawidłowo, potrzebuje wolnego miejsca na dysku. Niestety niewiedza użytkowników, którzy często wypełniają pamięć na maksa w połączeniu z write amplification powodują, że tego miejsca na dysku staje się coraz mniej. Producenci stosują różne metody umożliwiające identyfikację obszarów pamięci, które oprogramowanie dysku SSD może zwolnić bez uszkodzenia danych użytkownika. Najprostszą jest sytuacja, kiedy oprogramowanie SSD (czyli FTL) samo stwarza dane nieaktualne (jak w podanym wyżej przykładzie). Wtedy dysk na pewno „wie”, że stara kopia tych danych nie jest już potrzebna. Inaczej wygląda sytuacja, kiedy użytkownik opróżnia kosz czy w inny sposób kasuje niepotrzebne mu pliki. W dyskach typu HDD, kasowanie pliku powoduje, że zmienia się kilka bitów (tzw. flagów) w plikach służbowych, systemowych. Np. w systemie plików NTFS w przypadku skasowanego pliku zmienia się jeden bit w „głównej tabeli plików” (tzw. MFT – Master File Table) oraz kilka bitów w pliku $BitMap, który zawiera ewidencję wolnego miejsca na dysku. W rezultacie, miejsce, które dalej jest zajęte przez skasowany plik, jest oznaczane jako wolne, a system operacyjny przestaje dany plik „widzieć”. W systemie plików FAT, w przypadku usunięcia pliku pierwsza litera jego nazwy jest zastępowana przez symbol specjalny. Kiedy system operacyjny chce zapisać (na dysku) nowe dane, sprawdza wymienione wyżej „flagi”. Obszar LBA oznaczony jako wolny zostaje nadpisany. Inaczej sytuacja wygląda w dyskach SSD – kontroler dysku SSD przed tym, jak zapisać nowe dane, musi mieć do dyspozycji wolne miejsce, tj. uprzednio rozładowane bloki. Pomaga mu w tym TRIM, działanie którego opiszemy w następnej części.
