Ostatnio miałem okazję przetestować różne systemy plików dla pewnej aplikacji pracującej pod kontrolą systemu Linux. Aplikacja miała pracować m.in na dysku SSD i dodatkowo system plików musiał być odporny na niekontrolowane przerwy w zasilaniu (wywoływane np. przez użytkownika poprzez wyciągnięcie wtyczki z kontaktu).
Z przeprowadzonych przeze mnie badań systemy operacyjne można podzielić na grupy:
1. ext2, fat – systemy plików nieodporne na “pady zasilania” ale dosyć wydajne dla SSD .
2. ext3, reiserfs, jfs – systemy prowadzące tzw. dziennik zdarzeń (ang. journaling) i dzięki temu możliwe jest odzyskanie danych po awarii zasilania. Mogą się jednak zdarzyć przypadki gdy nie będzie to możliwe. W tej grupie najbardziej zawiódł mnie system plików JFS. Każda awaria kończyła się potrzebą uruchomienia programu fsck sprawdzającego spójność systemu. Dodatkowo działanie każdego z tych systemów plików może ukrócić czas działania flash-y zwłaszcza tych, bez tzw. “wear leveling”. Przyczyniają się do tego dodatkowe operacje wykonywane na dysku, czyli zapis dziennika zdarzeń. Dodatkowo ext3 wykonuje standardowo co 5s operację sync .
3. logfs, nilfs2 – systemy plików stworzone pod SSD. Niestety logfs nie udało mi się wkompilować w jądro. Natomiast nilfs bardzo mi się spodobał. System plików robi w trybie ciągłym tzw. migawki (ang. snapshots) z gwarancją, że nie zostaną one przez siebie nadpisane. Dzięki temu mamy pewność, że system plików pozostanie spójny, a stracić możemy jedynie ostatnie zmiany. W razie awarii zasilania, jądro systemu odzyska automatycznie ostatnią kopię z migawki.
Podsumowując, zostałem póki co przy nilfs2. Zobaczymy co czas pokaże…