Reiser4 vs ext4 - czy naprawdę są dla siebie konkurencją?
Reiser 4 ostatnio przechodzi kryzys. Do jądra wchodzi ext4 - wypowiedzi na większości serwisów są takie, że ext4 wyprze reisera4. Obawiam się, że te systemy plików konkurują ze sobą, mimo że są przeznaczone do całkowicie różnych celów.
Zarządzanie partycją
Oba systemy plików są oparte na zupełnie różnych filozofiach. Reisery pakuje kilka plików do jednego węzła. Co za tym idzie małe pliki nie zajmują całego bloku i w rezultacie oszczędzamy miejsce. Ext przeznacza dla pliku więcej miejsca, niż plik potrzebuje co ma zapobiegać fragmentacji. Oczywiście z tego powodu pliki są znacznie luźniej upakowane (dane muszą być rozrzucone po całej partycji). Nie ma także pakowania kilku plików do jednego węzła.
Dlatego Reiser lepiej nadaje się dla duzej ilości małych plików (/var/www, /home, /tmp, /usr/portage, odchudzonego /...). Ext3 lepiej nadaje się na większe pliki (baza danych na przykład).
Traktowanie plików
Ext prezentuje tradycyjne podejście do plików. Tzn. katalog to plik. Reiser4 prezentuje znacznie ciekawsze podejście. Tzn. plik to katalog. W tym systemie można np. potraktować plik OGG/Vorbis jako katalog z metadanymi (tzn. z plikiem Artist, Album, Year...).
Wadą tego rozwiązania jest to, że nikt się nim nie zajmuje - a wymagałoby to sporych zmian we wszystkim.
Plug-iny
Ostatnia rzeczą, o której wspomne są pluginy w Reiser4. Nie trzeba modyfikować kodu, żeby dodać nową funkcjonalność. Inne filesystemy na razie nawet chyba o tym nie marzą.
Stabilność i wydajność
Reiser4 cieszy się złą sławą. Moim zdaniem nieuzasadnioną - korzystałem z niego wiele razy - przerzywał odcięcia prądu i inny niespodzianki losu. Strat danych nie stwierdzono. O ext4 niestety nic nie wiem, ale ponoć działa stabilnie.
Reiser4 także (narazie) wyprzedza ext4 w odczycie małych plików, co, jak podejrzewam, jest najpopularniejszą operacją. Ext4 jednak znacznie wyprzedza ext3. Wyprzedza także reiser4 jeśli chodzi o zapis. Benchmark ext3, ext4 i reiser4 jest tutaj.
Podsumowując
Reiser4 wydaje się być idealnym systemem plików na typowy desktop(jednak nie dla tych, ze wzlędu na synchronizacje, które muszą być RTS). Reiserfs albo reiser4 na partycje z dużą ilością małych plików a ext4 na duże i średnie pliki.
Komentarze do wpisu
Możesz śledzić odpowiedzi poprzez kanał RSS. Możesz dodać komentarz lub zostawić ślad (trackback) ze swojego bloga.
Zboczuch
A co z XFS?
25 października 2006, 12:08:25
Uzytkownik
Nie znam, więc się nie wypowiem. Dyskusja toczy się niejako z pominięciem XFS i JFS. Chętnie dodam, jeśli ktoś da mi artykuły na ten temat.
25 października 2006, 12:37:23
Jajcuś
IMHO feature'y Riser4 to głównie rzeczy, które IMHO do systemu plików nie należą (jak już to do jakiejś warstwy VFS w userspace), albo optymalizacje, które dają IMHO pomijalny zysk kosztem stabilności, niezawodności, a nawet wydajności w niektórych zastosowaniach. Nie ma chyba w Riserfs nic co mogłoby mnie do niego zachęcić.
25 października 2006, 12:42:15
Uzytkownik
1. Jak mówię, nie spotkałem się ze spadkiem stabilności pod reiserem. EOT
2. Zaledwie 2x przyspieszenie w benchmarku robionym 'pod ext4' dla IMHO najpopularniejszej operacji - czytania małych plików. Moim zdaniem jest to istotne przyspieszenie. Reiser jest wyspecjalizowany do konkretnego celu - dużej ilości małych plików.
3. Kłopot jest jeden - nie jest to zaimplementowane w VFS.
Szczegolnie gdy jest to /etc/fstab ;)
25 października 2006, 12:48:59
Jajcuś
W którym VFS? W kernelowym? To takich rzeczy jak metadane z plików MP3/OGG jako pliki nie ma. I bardzo dobrze. I miejmy nadzieję, że nigdy nie będzie. Kernel nie powinien się takimi rzeczami zajmować (nie wiem jak jest to Riser4 rozwiązane... jeśli robi to kod w kernel-space, to taki system plików IMHO nadaje się tylko na śmietnik). W VFS KDE albo GNOME nie wiem czy jest. W Midnight Commanderze coś takiego jest (klepnij sobie Enter na pliku RPM) i to znacznie lepsze miejsce niż kernel albo "fizyczny" system plików.
Kolejna sprawa to mieszanie danych i metadanych. To dwie rozdzielne rzeczy i naturalnym jest używanie przynajmniej oddzielnych przestrzeni nazw do tego.
No i ostatnia sprawa... jakie widzisz sensowne zastosowanie takiego ficzera w filesystemie dyskowym? Wygoda użytkownika używającego menedżera plików? To niech będzie w tym menedżerze plików zaimplementowane. Do używania w aplikacjach? Nie chciałbym używać aplikacji, która działa tylko z jednym systemem plików... Nawet z MP3 na płytce CD (ISO 9660) by to nie działało.
Jeśli chodzi o czytanie wielu małych plików... to pewnie można inne systemy plików usprawnić. Tyle że nie będę ładował wielkiego kombajnu do kernela, żeby szybciej czytać małe pliki. Wolę te pliki zastąpić czymś innym.
25 października 2006, 13:05:52
Uzytkownik
1. Kwestia dyskusji. Na fragmenty pliku można by nakładać np. acl. Załóżmy, że mamy konfiguracyjny plik XML. Różne osoby potrzebują dostępu r/w do różnych części. Można stworzyć albo specjalny edytor z suid, albo xml-fuse albo z czegoś takiego. Dlaczego nie ma być (jeśli nie w jądrze to 'wyeksportowane do userspace)?
Emacs lub vim do edycji metadanych to kusząca propozycja :)
Zgadzam się, że powinno być to dostępne dla szerszej grupy filesystemów, ale jest jeden kłopot - rozpoznawanie typu pliku. Tzn. musi być zapisany typ MIME, a to powoduje że zmienia się filesystem. Można się opierać na Magick Noumber (zawodne np. dla plików tekstowych) lub rozszerzeniach.
2. Czasami do filesystemu potrzeba dodać funkcjonalność. Za mało znam się na Reiser4, ale podejrzewam, że Acl i Attr będą tam właśnie tak zaimplementowane.
3. Można korzystać z Reierfs. Kłopot z Reiser4 jest taki, że jak na desktop jest zbyt rewolucyjny, a na serwer nieprzydatny.
4. Jakie widze praktyczne zastosowanie? Choćby odchudzenie systemów wyszukujących (Beagle nie musi wiedzieć, jak plik jest zbudowany a locate może przeszukiwać pliki muzyczne).
5. Powtarzalność kodu. W Mc musi wiedzieć o rpm'ach, gnome-vfs musi wiedzieć o rpm'ach.
6. Czym zastąpisz te pliki np. w portage lub w tmp?
U siebie mam także kolekcje uporządkowanych małych plików, które przez to są łatwiejsze do zarządzania.
25 października 2006, 13:20:01
Jajcuś
Ad. 1., ad. 2. Do tego znacznie lepiej się nadaje fuse -- umożliwia w taki sposób rozszerzenie dowolnego istniejącego systemu plików (pliki składowane są normalnie w "normalnym" systemie plików, a podmontowane przez fuse gdzie indziej, już wraz z metadanymi), a cała logika pozostaje w userspace.
Ad. 5. Jak ktoś zrobi VFS w userspace który będzie mógł zaspokoić potrzeby wszystkich, to ten VFS się przyjmie.
25 października 2006, 13:34:56
Uzytkownik
Ad.1 Ad.2 Ale nadal potrzeba dwóch lokalizacji - bazowej i zamontowanej
Ad. 5. Pomijając zgodność wstecz, konieczność przepisania kodu itp.
25 października 2006, 13:38:06
Jajcuś
A myślisz, że ze względu na zmianę działania standardowych syscalli, takich jak open(), czy chdir() dla plików, czy niekonsekwencje w działaniu dla niektórych ścieżek (podejrzewam, że "pliki" metadanych nie będą się zawsze zachowywać dokładnie tak jak inne pliki) nie trzeba będzie nic poprawiać? Obawiam się, że poprawki mogłyby być potrzebne w aplikacjach, które wcale tych nowych ficzerów nie potrzebują.
25 października 2006, 13:43:03
Uzytkownik
Tak - i jest to także problem. Te funkcje Reiser4 (zarówno wady, jaki i zalety) są pomijane.
25 października 2006, 13:44:08
void
A z XFS jest to, że gubi dane jak się prąd wyłączy. Owszem, jest najszybszy, ale bez UPSa jest bez sensu. :/
25 października 2006, 13:54:30
rash
Szemrany ten test, zobacz coś bardziej dokładnego/wiarygodnego - http://linuxgazette.net/122/TWDT.html#piszcz
25 października 2006, 15:44:56
Dodaj komentarz