Systemy plików na pamięci Flash

Jacek Migdał

Wstęp

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.

Jak wygląda dysk HDD dla systemów plików

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.

Jak działa dysk SSD

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).

Jak korzystamy obecnie z dysku SSD?

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.

System plików jako log (Log-structured file systems)

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.

Istniejące implementacje

Żaden nie wspiera większości ciekawej funkcjonalności lub nie było tworzona stricte pod kątem SSD.

NilFS

Strona projektu

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).

LogFS

Strona projektu

Prosty, nie wspiera snapshotów. Montowanie w czasie O(log(n)).

JFFS2

Strona projektu

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

ZFS

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.

Btrfs

Strona projektu

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).

Bazy danych korzystające z SSD

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.

Podsumowanie

Systemy plików w oparciu o logi dla SSD to ciekawy pomysł, ale implementacje są jeszcze w fazie rozwoju.

Zalety:

Problemy/wyzwania:

Źródła


Janina Mincer-Daszkiewicz