ReiserFS i Reiser4

Łukasz Kożuchowski lk178865@students.mimuw.edu.pl
13.01.2004

1. ReiserFS w wersji 3

System ReiserFS bierze swoją nazwę od nazwiska twórcy Hansa Reisera z firmy Namesys. Jest to system powstały z myślą o linuksie, w przeciwieństwie do takich systemów jak JFS, czy XFS, które zostały na linuksa przeniesione z innych systemów operacyjnych.

Przy projektowaniu swojego systemu Hans Reiser przyjął dwa założenia:

W rzeczywistych systemach większość plików to pliki małe (mniejsze niż rozmiar bloku). Takie systemy jak EXT2, EXT3, FAT16, FAT32, NTFS, FFS i inne marnują miejsce alokując cały blok na jeden pojedynczy mały plik. Warto to miejsce zaoszczędzić. Oprócz oszczędności miejsca ważna jest również szybkość. Należy zwrócić uwagę na szybką obsługę dużej ilości małych plików.
Drugim założeniem było stworzenie ujednoliconego interfejsu dla plików, katalogów i metadanych, który zapewniłby podobny dostęp do wszystkich tych rodzajów danych w systemie plików.

Cechy ReiserFS

ReiserFS v3 przechowuje dane w strukturze B+ drzewa, w tej strukturze znajdują się zarówno pliki, katalogi jak i metadane. Małe pliki upychane są w blokach tak, żeby nie marnowały miejsca. ReiserFS jest kronikowanym systemem plików (domyślnie kronikuje się wyłącznie metadane).

B+ drzewa w ReiserFS v3

B+ drzewo przechowuje w liściach dane rozmiaru bloku (taki jest rozmiar każdego węzła w B+ drzewie). Dane w liściach nazywa się "pozycjami" (ang. items). W ReiserFS v3 wyróżniamy cztery rodzaje pozycji:

Dane katalogu

zawierają wpisy katalogowe (nazwy pozycji w katalogu i ich klucze w drzewie).

Dane informacyjne (Stat)

zawierają atrybuty: typ pliku, właściciela i uprawnienia do pliku, jego wielkość itp. informacje w innych systemach plików przechowane w i-węzłach.

Dane bezpośrednie

zawierają małe (mieszczące się w jednym bloku) pliki a także "ogony" dużych plików tj. mniejsze od rozmiaru bloku końcówki plików podzielonych na bloki ("reszta z dzielenia").

Dane pośrednie

to wskaźniki do tzw. węzłów niesformatowanych, tj. obszarów zajętych dużymi plikami (ang. BLOB - Binary Large OBject). Te duże pliki znajdują się w drzewie o jeden poziom niżej od liści (nie są to w ścisłym teoriografowym sensie liście, bo wychodzą z tych węzłów krawędzie w dół). Pokazuje to poniższy rysunek.

B+ drzewo w ReiserFS v3

Na rysunku jasnozielone węzły to liście przechowujące pozycje. Węzły niesformatowane przedstawione są w kolorze ciemnozielonym.

2. Reiser4 (ReiserFS w wersji 4)

Nowa wersja ReiserFS została napisana od zera. Zmiany w stosunku do wersji 3 są na tyle znaczne, że zasadne jest używanie nowej nazwy: Reiser4, zamiast ReiserFS. Tym razem twórca położył nacisk na bezpieczeństwo. Reiser4 ma być systemem dla wojska, choć oczywiście ma być również używany przez ludność cywilną. Prace nad tym systemem plików sponsoruje DARPA (Defence Advanced Research Project Agency). Reiser4 nie jest jeszcze ukończony.

Zmiana struktury danych

B+ drzewa zostały w nowej wersji zastąpione "drzewami tańczącymi" (dancing tree). W drzewie tańczącym wskaźniki do węzłów niesformatowanych przechowujemy poziom wyżej nad liścmi, tzn. węzły niesformatowane znajdują się na poziomie liści (jak na rysunku poniżej). drzewo tanczace w reiser4

W zwykłych B+ drzewach po każdej operacji zapewniamy spełnianie warunków B+ drzewa, co jest dosyć kosztowne. Doświadczenia pokazały, że opłaca się opóźniać równoważenie drzewa. Dlatego drzewo tańczące (i stąd zapewne jego nazwa) aktualizuje swoją strukturę dopiero po wykonaniu operacji commit przez pewien okres czasu pozostając niezrównoważone. Nie istnieją racje matematyczne, aby przyjąć takie postępowanie, jest ono podyktowane doświadczeniem.

Wędrujący dziennik (ang. wandering log)

Zwykłe kronikowanie jest dosyć kosztowne, bo wymaga dwukrotnego zapisu danych na dysk - do dziennika i na miejsce docelowe. W Reiser4 wprowadzono nowatorskie rozwiązanie pozwalające na jednokrotny zapis na dysku. Gdy zapisywanie do dziennika zostaje zakończone, status bloku w którym mamy zapisany dziennik zmienia się i blok staje się "normalnym" elementem systemu plików, gdy tymczasem dziennik zmienia swoje położenie na dysku. Daje to oczywiście duże przyspieszenie.

Mechanizm wtyczek (plugins)

Reiser4 ma modularną budowę dzięki mechanizmowi wtyczek. Jest osiem rodzajów wtyczek:

file plugins - udostępniają metody dostępu do plików
directory plugins - udostępniają metody dostępu do plików
hash plugins - obsługują haszowanie kluczy w drzewie tańczącym
security plugins - obsługują bezpieczeństwo
item plugins - udostępniają metody dostępu do pozycji
key assignment plugins - zajmują się przydzielaniem kluczy w drzewie
node search and item search plugins - odpowiedzialne za wyszukiwanie w drzewie węzłów i pozycji

Udostępniono możliwość stworzenia nowych rodzajów wtyczek.

Rozmycie rozróżnienia na pliki i katalogi

Zwykle myślimy o pliku jak o ciągu bajtów, a o katalogu jak o zbiorze plików. W Reiser4 podjęto próbę pełniejszej realizacji uniksowego postulatu "wszystko jest plikiem". Mechanizm wtyczek pozwala nam traktować każdy zasób w systemie jak plik, lub jak katalog.

Wyobraźmy sobie, że mamy plik foo.mp3, możemy go traktować na dwa sposoby:

foo.mp3 - jak zwykły plik
foo.mp3/ - jak katalog

Katalog foo.mp3/ mógłby zawierać zwykłe atrybuty pliku:

foo.mp3/owner
foo.mp3/size
itp.

a także dowolne informacje, np. te, które dziś przechowujemy w ID3 Tag.

foo.mp3/artist
foo.mp3/title
foo.mp3/album
foo.mp3/genre

Po co mielibyśmy tak robić? ID3 Tag jest mało elastyczny, wciąż powstają jego nowe wersje. Rozwiązanie Reiser4 pozwoliłoby nam zapisywać dowolne informacje o pliku i uzyskiwać do nich łatwy dostęp. Metadane pliku graficznego mogłyby przechowywać miniaturę (foo.jpg/thumbnail), a nawet wirtualnie istniejące wersje tego pliku w innych formatach (foo.jpg/foo.png). Może się zdarzyć, że jakaś aplikacja dopisze do pliku nowe metadane, a my usuniemy aplikację i utracimy pożytek z tych metadanych (możemy nawet o nich nie wiedzieć). Grozi nam, że w systemie plików pojawią się niechciane dane ("śmieci") zapychające dysk. Jest to jedno z zastrzeżeń, które często formułowane są pod adresem rozwiązań Reiser4.

Typy MIME plików

Również typy plików warto by przechowywać wraz z plikiem w jego metadanych. W tej chwili polegamy na trójliterowych rozszerzeniach. Ma to pewne przykre konsekwencje. Nie posiadamy "pełni władzy" nad nazwą pliku, nie możemy nadać mu dowolnej nazwy bez ryzyka, że plik nie zostanie otwarty w odpowiedniej aplikacji. Podczas przenazwowania pliku zdarzają się literówki, które powodują właśnie takie trudności z otwarciem pliku. Z tego powodu wiele aplikacji ukrywa przed użytkownikiem trójliterowe rozszerzenie. To z kolei prowadzi do sytuacji, gdy użytkownik nie wie, kiedy rozszerzenie jest ukryte, a kiedy nie. Zdarza się, że użytkownik tworzy przez to np. plik o nazwie page.html.txt.

Zapis typu pliku w atrybutach wykorzystano już w MacOS. Stwarza to użytkownikom tego systemu trudności z przenoszeniem swoich plików na inne systemy, czy przesyłem tych plików przez internet. Widać konieczność opracowania nowych standardów transmisji. Jest to kolejna przyczyna sceptycyzmu wobec Reiser4.

Bezpieczeństwo

Reiser4 pozwala na prostszą (dzięki temu skuteczniejszą) politykę bezpieczeństwa. W tej chwili informacje o kontach przechowywane są w dwóch plikach: /etc/passwd oraz /etc/shadow. Mamy informacje o czasie ostatnich modyfikacji tych plików, ale nie posiadamy wiedzy, o tym, które pola tych plików były zmieniane. Możemy wiedzieć, że ktoś zmienił hasło, ale nie wiemy czyje. Problemem jest również takie zapewnienie dostępu do obu plików, aby każdy mógł mieć do nich dostęp (każdy może zmienić swoje hasło), ale aby nikt nie mógł zmienić cudzego hasła.

Proponowane rozwiązanie:

W Reiser4 każdy użytkownik miałby dostęp do katalogu:

/etc/passwd/107/

gdzie 107 jest przykładowym numerem użytkownika. Pliki w tym katalogu odpowiadałyby polom z plików /etc/passwd i /etc/shadow. Zmiana domyślnej powłoki mogłaby zostać dokonana np. tak:

echo 'bin/bash' > /etc/passwd/107/shell

Każdy użytkownik miałby dostęp wyłącznie do swojego katalogu /etc/passwd/UID. Znalibyśmy czas modyfikacji poszczególnych pól w /etc/passwd.

To rozwiązanie możnaby wprowadzić już teraz (bez Reiser4), tworząc w miejsce pliku /etc/passwd katalog /etc/passwd/ z odpowiednimi podkatalogami, ale

większość istniejących systemów plików zajmuje zbyt dużo miejsca na małe pliki (może być wielu użytkowników i odpowiadających im małych plików w katalogach /etc/passwd/* ). Reiser4 oszczędza miejsce na małe pliki.
istniejące oprogramowanie odwołuje się do pliku /etc/passwd. Tylko mechanizm wtyczek, umożliwiając różne sposoby dostępu do tego samego zasobu, pozwala na wprowadzenie takiego rozwiązania bez problemów ze starym oprogramowaniem.

Katalog też jest plikiem!

Podobnie jak plik, katalog również można odczytać na dwa sposoby. Katalog traktowany jak plik zawiera spis nazw pozycji katalogu odseparowanych jakimś znakiem (np. '\n'). Do zawartości katalogu uzyskujemy "normalny" dostęp jak do pliku. Jest to jeszcze niezaimplementowane.

Podsumowanie

Reiser4 jest wciąż niegotowy, miał się ukazać już na początku 2003 roku, w tej chwili jest w wersji beta i jest jeszcze poprawiany. Reiser4 wzbudza wielkie nadzieje, ale często zgłaszane są też wątpliwości co do użyteczności proponowanych rozwiązań.

Wydajność

Wydajność ReiserFS v3 jest porównywalna do EXT2, jego przewaga ujawnia się, gdy testy przeprowadzamy dla małych plików. Wejście za pomocą programu mc do katalogu /dev jest zauważalnie szybsze w systemie ReiserFS.

Różne testy wydajności systemów plików dają bardzo różne wyniki, zależnie od tego, kto i jak je robił.

Testy wydajności Reiser4 na stronie www.namesys.com pokazują, że przy założeniu, że 80% plików ma rozmiar do 8kB jest to system szybszy niż ext2, ext3, reiserFS v3, JFS, XFS.

Na stronie www.gurulabs.com/ext3-reiserfs.html przedstawione są niekorzystne dla ReiserFS v3 wyniki porównań tego systemu plików z EXT3

Źródła

Materiały do prezentacji pochodzą przede wszystkim ze stron: