Pamięć Flash powoli staję się atrakcyjną alternatywą dla dysków twardych. Obecne wiodące systemy plików (NTFS, ext2/3, ...) zostały zaprojektowane pod kątem dysków HDD. Dyski zbudowane z pamięci Flash - SSD (Solid State Drive) działają zupełnie inaczej. Mają wysoką wydajność, także w niesekwencyjnym odczycie/zapisie. Z drugiej strony mają ograniczoną liczbę cykli zapisu i kasowanie danych jest bardziej problematyczne. Obecnie te różnice maskuję się w kontrolerach dysków SSD, ale lepszym rozwiązaniem byłoby stworzenie nowego systemu plików pod kątem SSD.
Upraszczając, oferuje N bloków. Dla każdego z nich można wykonać operacje zapisu lub odczytu.
Interfejs ten nazwy się ATA, schemat adresowania to LBA, blok zwykle ma wielkość 512 bajtów.
Czytanie, pisanie do kolejnych bloków ma dużą wydajność. Losowy dostęp jest wolny.
Dysk jest podzielony na bloki (blocks), a bloki na strony (pages).
Blok jest to najmniejsza jednostka, którą można usuwać - zamieniać zawartość na same 1.
Strona to jest najmniejsza jednostka, którą można czytać lub pisać, ale tylko tak by zamieniać część 1 na 0.
Typowy dysk SSD ma stronę wielkości 512 - 4096 B i jest 32-128 stron w jednym bloku.
Ilość kasowań jednego bloku jest ograniczona (zwykle 10 000 - 100 0000).
Kontroler pamięci emuluje interfejs ATA. Maskuję różnice pomiędzy dyskami SSD, a HDD. W szczególności zajmuję się odśmiecaniem (GC) i przesuwaniem danych tak by mieścić się w limicie zapisu.
Przed odśmiecaniem: (jedynie strony błękitna i pomarańczowa są aktualne)
Źródło: http://www.devwhy.com/blog
Po odśmiecaniu:
Źródło: http://www.devwhy.com/blog
Aby odśmiecanie działało efektywnie kontroler SSD musi wiedzieć, które strony są aktualne. W podstawowej wersji ATA nie ma takiej informacji. Dane są jedynie nadpisywane. Informację tą można przekazać w komendą ATA Trim, która daję informację, że pewne dane nie będą już nigdy wykorzystane.
Na tym działa standardowy system plików, jedynie jego opcje są dobrane do wielkości bloków i stron. Do efektywnego działania powinnien wspierać komendę ATA Trim. Jest ona wspierana przez Linux >= 2.6.33, Windows 7 i ma być wspierana przez Mac OS X Lion.
Zaprojektowany od początku pod kątem SSD. Dane i metadane są tylko zapisywane na końcu, tworząc cykliczny log. Bloki są czyszczone przez odśmiecacz (GC). Umożliwia to łatwe tworzenie snapshot i wersjonowanie systemu plików.
Dodatkową motywacją jest stworzenie systemu pliku, który zapewni szybkie przywracanie danych. Odwracanie zmian na dysku pozwoliłoby uniknąć dużej części awarii.
Źródło: http://www.nilfs.org/papers/jls2009-nilfs.pdf
Główną idea, polega na stosowaniu funkcyjnych struktur danych (drzew, list, ...). Wtedy zmiana danych ogranicza się do dodania nowych elementów i ustawieniu by ich wskaźniki wskazywały na te już istniejące.
Źródło: http://www.nilfs.org/papers/jls2009-nilfs.pdf
W tym modelu trzeba w każdym punkcie kontrolnym przepisać superbloku. Z drugiej strony do przywrócenia poprzedniej wersji wystarczy podmontować stary superblok. Dzięki temu można zrezygnować z stoswania dziennika zmian (journaling) i skomplikowanych procedur odtworzenia.
Źródło: http://www.nilfs.org/papers/jls2009-nilfs.pdf
O ile w miarę prosto zaimplementować szkielet systemu, to problematyczny jest odśmiecacz. W szczególności odśmiecanie elementów drzewa plików jest skomplikowane.
Żaden nie wspiera większości ciekawej funkcjonalności lub nie było tworzona stricte pod kątem SSD.
Mocny nacisk na robienie snapshot, słabe/brak wsparcia dla SSD (działa na urządzeniu blokowym). Można jednocześnie czytać ze snapshotów podczas korzystania z dysku. Jest na licencji GPL i dostał się do oficjalnego repozytorium Linuxa (> 2.6.30).
Prosty, nie wspiera snapshotów. Montowanie w czasie O(log(n)).
Nie przechowuje drzewa katalogów na dysku. Montowanie w czasie O(n). Nie wspiera snapshotów. W praktyce nadaję się tylko do małych nośników
Bardzo zaawansowany system plików tworzony przez system Sun. Używany na długo przed powstaniem komercyjnych SSD. Ma bardzo wiele ciekawych funkcjonalności, ale do pełnego ich wsparcia wymaga sprzętu (np. baterii do podtrzymywania napięcia). Tworzony pod kątem serwerów. Udostępniony na licencji open source CDDL, co w praktyce uniemożliwia wykorzystania jego w Linux.
Bardzo złożony i zaawansowany system plików, w założeniu ma być odpowiednikiem ZFS na licencji GPL. Projektowany głównie do serwerów, niekoniecznie z dyskami SSD (brak pełnego ich wsparcia).
Firma RethinkDB tworzy logową bazę danych ukierunkowaną na dyski SSD. Działa podobnie jak systemy plików, z tym że obiektami są wiersze w tabelach. Działa jako silnik MySQL.
Systemy plików w oparciu o logi dla SSD to ciekawy pomysł, ale implementacje są jeszcze w fazie rozwoju.
Zalety:
Problemy/wyzwania:
Janina Mincer-Daszkiewicz |