ReiserFS

ReiserFS 3.6
Deweloperzy Nazwy
Pełne imię i nazwisko ReiserFS
wprowadzony 2001 ; 22 lata temu ( 2001 ) z Linuksem 2.4.1
Identyfikator partycji
Struktury
Zawartość katalogu drzewo B+
Alokacja plików Mapa bitowa
Granice
Maks. rozmiar woluminu 16 TiB
Maks. rozmiar pliku 1 EiB (8 TiB w systemach 32-bitowych)
Maks. liczba plików 2 32-3 (~ 4 miliardy)
Maks. długość nazwy pliku 4032 bajtów, ograniczone do 255 przez Linux VFS
Dozwolone znaki w nazwach plików Wszystkie bajty z wyjątkiem NUL i „/”
Cechy
Zapisane daty Modyfikacja (mtime), zmiana metadanych (ctime), dostęp (atime)
Zakres dat 14 grudnia 1901 - 18 stycznia 2038 (32-bitowy czas Uniksa)
Rozdzielczość daty 1 sek
widelce Rozszerzone atrybuty
Uprawnienia systemu plików Uprawnienia systemu Unix, listy ACL i dowolne atrybuty bezpieczeństwa
Przezroczysta kompresja NIE
Przejrzyste szyfrowanie NIE
Inny
Obsługiwane systemy operacyjne Linuks, ReactOS

ReiserFS to uniwersalny system plików z dziennikiem , pierwotnie zaprojektowany i wdrożony przez zespół Namesys kierowany przez Hansa Reisera i licencjonowany na licencji GPLv2 . Wprowadzony w wersji 2.4.1 jądra Linuksa , był to pierwszy system plików z dziennikiem, który został włączony do standardowego jądra. ReiserFS był domyślnym systemem plików w Novell , dopóki Novell nie zdecydował się na przejście do ext3 w dniu 12 października 2006 r. w celu udostępnienia przyszłych wydań.

Namesys uznał ReiserFS w wersji 3.6, która wprowadziła nowy format na dysku umożliwiający większe rozmiary plików, obecnie czasami określany jako Reiser3, za stabilny i kompletny w zakresie funkcji i, z wyjątkiem aktualizacji bezpieczeństwa i krytycznych poprawek błędów, zaprzestał rozwijania go, aby skoncentrować się na jego następca, Reiser4 . Namesys zbankrutował w 2008 roku po skazaniu Reisera za morderstwo. Produkt jest teraz utrzymywany jako open source przez wolontariuszy. Reiserfsprogs 3.6.27 zostały wydane 25 lipca 2017 r.

ReiserFS jest obecnie obsługiwany w systemie Linux bez obsługi przydziałów. Dyskutowano o usunięciu go z jądra Linuksa od początku 2022 roku z powodu braku konserwacji w górę i problemów technicznych związanych z systemem plików, takich jak fakt, że cierpi na problem z rokiem 2038 ; został wycofany w Linuksie 5.18, a usunięcie planowane jest na 2025 rok.

Cechy

W momencie wprowadzenia ReiserFS oferował funkcje, które nie były dostępne w istniejących systemach plików Linux. Jednym z przykładów jest upakowanie ogona — schemat mający na celu zmniejszenie wewnętrznej fragmentacji kosztem wydajności. Reiser4 mógł to poprawić, umieszczając ogony tam, gdzie nie wpływa to negatywnie na wydajność.

Projekt

ReiserFS przechowuje metadane plików („pozycje statystyk”), wpisy katalogów („pozycje katalogów”), listy bloków i-węzłów („pozycje pośrednie”) i ogony plików („pozycje bezpośrednie”) w jednym połączonym drzewie B + kluczowane przez uniwersalny identyfikator obiektu. Bloki dysku przydzielone do węzłów drzewa to „sformatowane bloki wewnętrzne”. Bloki węzłów liści (w których elementy są pakowane od końca do końca) to „sformatowane bloki liści”. Wszystkie inne bloki są „niesformatowanymi blokami” zawierającymi zawartość pliku. Elementy katalogu ze zbyt dużą liczbą wpisów lub elementy pośrednie, które są zbyt długie, aby zmieścić się w węźle, przechodzą do sąsiedniego prawego liścia. Alokacja bloków jest śledzona przez bitmapy wolnego miejsca w ustalonych lokalizacjach.

Dla kontrastu, ext2 i inne systemy plików podobne do Berkeley FFS z tamtych czasów po prostu używały ustalonej formuły do ​​obliczania lokalizacji i-węzłów, ograniczając w ten sposób liczbę plików, które mogą zawierać. Większość takich systemów plików przechowuje również katalogi jako proste listy wpisów, co powoduje, że wyszukiwanie katalogów i aktualizacje są liniowymi operacjami w czasie i obniżają wydajność bardzo dużych katalogów. Pojedynczy drzewa B+ w ReiserFS pozwala uniknąć obu tych problemów dzięki lepszym właściwościom skalowalności.

Wydajność

W porównaniu z ext2 i ext3 w wersji 2.4 jądra Linuksa, gdy mamy do czynienia z plikami poniżej 4 KiB i z włączonym pakowaniem ogona, ReiserFS może być szybszy.

Przed Linuksem 2.6.33 ReiserFS intensywnie używał dużej blokady jądra (BKL) — globalnej blokady całego jądra — która nie skaluje się dobrze w systemach z wieloma rdzeniami, ponieważ krytyczne części kodu są zawsze wykonywane tylko przez jeden rdzeń na raz .

Stosowanie

ReiserFS był domyślnym systemem plików w SuSE Linux od wersji 6.4 (wydanej w 2000 roku), aż do przejścia na ext3 w SUSE Linux Enterprise 10.2 i openSUSE 11, ogłoszonego w 2006 roku.

Jeff Mahoney z SUSE napisał post 14 września 2006 r., Proponując przejście z ReiserFS na ext3 dla domyślnego instalacyjnego systemu plików. Niektóre powody, o których wspomniał, to skalowalność, „problemy z wydajnością z rozszerzonymi atrybutami i listami ACL ”, „mała i kurcząca się społeczność programistów” oraz to, że „ Reiser4 nie jest aktualizacją przyrostową i wymaga ponownego formatowania, co jest nierozsądne dla większości ludzi”. 4 października napisał odpowiedź na blogu, aby wyjaśnić pewne kwestie. Napisał, że jego propozycja zamiany nie miała związku z toczeniem procesu Hansa Reisera za morderstwo. [ nieudana weryfikacja ] Mahoney napisał, że „obawiał się, że ludzie nawiążą kontakt tam, gdzie go nie było” oraz że „czas jest całkowicie przypadkowy, a motywacja nie ma związku”.

Krytyka

Niektóre operacje na katalogach (w tym unlink (2)) nie są synchroniczne w ReiserFS, co może spowodować uszkodzenie danych w aplikacjach polegających w dużym stopniu na blokadach opartych na plikach (takich jak agenty przesyłania poczty qmail i Postfix ), jeśli maszyna zatrzyma się przed zsynchronizowaniem dysk.

Nie ma programów specjalnie defragmentujących system plików ReiserFS, chociaż napisano narzędzia do automatycznego kopiowania zawartości pofragmentowanych plików, mając nadzieję, że można znaleźć więcej ciągłych bloków wolnego miejsca. Jednak dla następnego systemu plików Reiser4 zaplanowano narzędzie „przepakowujące”, które miałoby radzić sobie z fragmentacją plików. Fragmentacja jest nadal problemem w przypadku dysków SSD niezależnie od systemu plików.

fsck

Fsck ReiserFS 3 jest w stanie odbudować całe drzewo w ramach ratowania w przypadku jego całkowitego uszkodzenia. Ta akcja musi być jawnie zainicjowana przez administratora i nie jest częścią normalnej pracy. Zgodnie z przewidywaniami proces ten jest destrukcyjny i może dodatkowo uszkodzić istniejące pliki lub wprowadzić nowe wpisy z nieoczekiwaną zawartością, co zostało skrytykowane jako metoda mniej niż optymalna.

partycji ReiserFS v3 (np. kopie zapasowe lub obrazy dysków dla emulatorów) bez ich przekształcenia (np. poprzez kompresję lub szyfrowanie), aby uniknąć pomyłek podczas odbudowy. Ponowne sformatowanie istniejącej partycji ReiserFS v3 może również pozostawić dane, które mogą zakłócić operację odbudowy i spowodować ponowne pojawienie się plików ze starego systemu. Pozwala to również złośliwym użytkownikom na celowe przechowywanie plików, które dezorientują narzędzie do odbudowy. Ponieważ metadane są zawsze w spójnym stanie po sprawdzeniu systemu plików, korupcja tutaj oznacza, że ​​zawartość plików jest łączona w nieoczekiwany sposób z metadanymi zawartego systemu plików. Jest to podobne do problemu FSID w btrfs . Następca ReiserFS, Reiser4, rozwiązuje ten problem.

Wcześniejsze problemy

ReiserFS w wersjach jądra Linuksa przed 2.4.16 zostały uznane przez Namesys za niestabilne i niezalecane do użytku produkcyjnego, zwłaszcza w połączeniu z NFS .

Wczesne implementacje ReiserFS (przed tą w Linuksie 2.6.2) były również podatne na zagrożenia związane z zapisem poza kolejnością. Ale obecna implementacja kronikowania w ReiserFS jest teraz na równi z „uporządkowanym” poziomem kronikowania ext3 . [ potrzebne źródło ]

Zobacz też

Linki zewnętrzne