wew3 - ext3

Dla genu, patrz EXT3 (gen) .
wew3
Deweloper(zy) Stephen Tweedie
Pełne imię i nazwisko Trzeci rozszerzony system plików
Wprowadzono Listopad 2001 z Linuksem 2.4.15
Identyfikator partycji 0x83 ( MBR )
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ( GPT )
Struktury
Zawartość katalogu Tabela, zaszyfrowane B-drzewo z włączonym dir_index
Przydział plików bitmapa (wolne miejsce), tabela (metadane)
Złe bloki Tabela
Limity
Maks. wielkość woluminu 4 TiB – 32 TiB
Maks. rozmiar pliku 16 GiB – 2 TiB
Maks. liczba plików Zmienna, przydzielona w czasie tworzenia
Maks. długość nazwy pliku 255 bajtów
Dozwolone znaki w nazwach plików Wszystkie bajty z wyjątkiem NUL ('\0') i '/'
Cechy
Daty zarejestrowania modyfikacja (mtime), modyfikacja atrybutu (ctime), dostęp (atime)
Zakres dat 14 grudnia 1901 – 18 stycznia 2038
Rozdzielczość daty 1 s
Atrybuty allow-unelete, append-only, h-tree (katalog), niezmienny, dziennik, no-atime, no-dump, secure-delete, synchronous-write, top (katalog)
Uprawnienia systemu plików Uprawnienia Unix, listy ACL i dowolne atrybuty bezpieczeństwa (Linux 2.6 i nowsze)
Przezroczysta kompresja Nie
Przejrzyste szyfrowanie Nie (dostępne na poziomie urządzenia blokowego)
Deduplikacja danych Nie
Inne
Obsługiwane systemy operacyjne Linux , BSD , ReactOS , Windows (poprzez IFS )

ext3 lub trzeci rozszerzony system plików to system plików z dziennikiem , powszechnie używany przez jądro Linuksa . Kiedyś był to domyślny system plików dla wielu popularnych dystrybucji Linuksa . Stephen Tweedie po raz pierwszy ujawnił, że pracował nad rozszerzeniem ext2 w Journaling the Linux ext2fs Filesystem w artykule z 1998 r., a później w lutym 1999 r. na liście dyskusyjnej jądra. System plików został połączony z głównym jądrem Linuksa w listopadzie 2001, począwszy od 2.4.15. Jego główną przewagą nad ext2 jest kronikowanie , które poprawia niezawodność i eliminuje potrzebę sprawdzania systemu plików po nieczystym zamknięciu. Jego następcą jest ext4 .

Zalety

Wydajność (szybkość) ext3 jest mniej atrakcyjna niż konkurencyjnych linuksowych systemów plików, takich jak ext4, JFS , ReiserFS i XFS , ale ext3 ma znaczną przewagę, ponieważ umożliwia uaktualnianie na miejscu z ext2 bez konieczności tworzenia kopii zapasowych i przywracania danych . Benchmarki sugerują, że ext3 również zużywa mniej mocy procesora niż ReiserFS i XFS. Jest również uważany za bezpieczniejszy niż inne systemy plików Linux, ze względu na względną prostotę i szerszą bazę testową.

ext3 dodaje następujące funkcje do ext2:

  • czasopismo
  • Rozwój systemu plików online
  • Indeksowanie Htree dla większych katalogów

Bez tych funkcji każdy system plików ext3 jest również prawidłowym systemem plików ext2. Ta sytuacja pozwoliła na używanie dobrze przetestowanych i dojrzałych narzędzi do obsługi systemu plików do konserwacji i naprawy systemów plików ext2 z ext3 bez większych zmian. Systemy plików ext2 i ext3 korzystają z tego samego standardowego zestawu narzędzi, e2fsprogs , który zawiera narzędzie fsck . Bliski związek sprawia również, że konwersja między dwoma systemami plików (zarówno naprzód na ext3, jak i wstecz na ext2) jest prosta.

ext3 nie ma "nowoczesnych" funkcji systemu plików, takich jak dynamiczna alokacja i- węzłów i ekstenty . Taka sytuacja może czasami być wadą, ale w przypadku możliwości odzyskania jest to znacząca zaleta. Metadane systemu plików znajdują się w stałych, dobrze znanych lokalizacjach, a struktury danych mają pewną nadmiarowość. W przypadku znacznego uszkodzenia danych, ext2 lub ext3 można odzyskać, podczas gdy system plików oparty na drzewie może nie.

Limity rozmiaru

Maksymalna liczba bloków dla ext3 to 2 32 . Rozmiar bloku może się różnić, wpływając na maksymalną liczbę plików i maksymalny rozmiar systemu plików:

Rozmiar bloku Maksymalny
rozmiar pliku 		Maksymalny
rozmiar systemu plików
1 KiB 16 GiB 2 TiB
2 KiB 256 GiB 8 TiB
4 KiB 2 TiB 16 TiB
8 KiB 2 TiB 32 TiB
  1. ^ W Linuksie rozmiar bloku 8 KiB jest dostępny tylko na architekturach, które dopuszczają strony 8 KiB, takich jak Alpha .

Poziomy księgowania

W linuksowej implementacji ext3 dostępne są trzy poziomy księgowania :

Dziennik (najniższe ryzyko)
Zarówno metadane, jak i zawartość pliku są zapisywane w dzienniku przed zatwierdzeniem w głównym systemie plików. Ponieważ dziennik jest względnie ciągły na dysku, może to poprawić wydajność, jeśli dziennik ma wystarczającą ilość miejsca. W innych przypadkach wydajność spada, ponieważ dane muszą być zapisywane dwukrotnie — raz do dziennika, a drugi raz do głównej części systemu plików.
Zamówione (średnie ryzyko)
Kronikowane są tylko metadane; zawartość pliku nie jest, ale gwarantuje się, że zawartość pliku zostanie zapisana na dysku, zanim skojarzone metadane zostaną oznaczone jako zatwierdzone w dzienniku. Jest to ustawienie domyślne w wielu dystrybucjach Linuksa. W przypadku przerwy w dostawie prądu lub paniki jądra podczas zapisywania lub dopisywania pliku, dziennik wskaże, że nowy plik lub dołączone dane nie zostały „zatwierdzone”, więc zostaną wyczyszczone przez proces czyszczenia. (Dlatego nowe pliki mają ten sam poziom ochrony integralności, co poziom „kronikowany”). Jednak nadpisywane pliki mogą zostać uszkodzone, ponieważ oryginalna wersja pliku nie jest przechowywana. W ten sposób można skończyć z plikiem w stanie pośrednim między nowym a starym, bez wystarczających informacji do przywrócenia jednego lub drugiego (nowe dane nigdy nie trafiły w całości na dysk, a stare dane nie są nigdzie przechowywane). Co gorsza, stan pośredni może przeplatać stare i nowe dane, ponieważ kolejność zapisu zależy od sprzętu dysku.
Zwrot (najwyższe ryzyko)
Kronikowane są tylko metadane; zawartość pliku nie jest. Treść może być napisana przed lub po aktualizacji czasopisma. W rezultacie pliki zmodyfikowane tuż przed awarią mogą ulec uszkodzeniu. Na przykład dodawany plik może zostać oznaczony w dzienniku jako większy niż w rzeczywistości, powodując śmieci na końcu. Starsze wersje plików mogą również pojawiać się nieoczekiwanie po odzyskaniu dziennika. Brak synchronizacji między danymi a dziennikiem jest w wielu przypadkach szybszy. JFS używa tego poziomu kronikowania, ale zapewnia, że ​​wszelkie „śmieci” z powodu niezapisanych danych zostaną wyzerowane po ponownym uruchomieniu. XFS również używa tej formy kronikowania.

We wszystkich trzech trybach wewnętrzna struktura systemu plików jest spójna nawet po awarii. W każdym razie tylko zawartość danych plików lub katalogów, które były modyfikowane podczas awarii systemu, zostanie naruszona; reszta będzie nienaruszona po wyzdrowieniu.

Niedogodności

Funkcjonalność

Ponieważ ext3 ma być wstecznie kompatybilny z wcześniejszym ext2, wiele struktur na dysku jest podobnych do tych z ext2. W związku z tym ext3 nie posiada najnowszych funkcji, takich jak ekstenty , dynamiczna alokacja i- węzłów i podrzędna alokacja bloków . Katalog może mieć maksymalnie 31998 podkatalogów , ponieważ i-węzeł może mieć maksymalnie 32 000 łączy (każdy bezpośredni podkatalog zwiększa licznik łączy i-węzłów folderu nadrzędnego w odwołaniu „..”).

ext3, podobnie jak większość obecnych systemów plików Linuksa, nie powinien być -edowany fsck, gdy system plików jest montowany do zapisu. Próba sprawdzenia systemu plików, który jest już zamontowany w trybie odczytu/zapisu, (bardzo prawdopodobne) wykryje niespójności w metadanych systemu plików. Tam, gdzie metadane systemu plików ulegają zmianie, a fsck stosuje zmiany, próbując doprowadzić „niespójne” metadane do „spójnego” stanu, próba „naprawienia” niespójności spowoduje uszkodzenie systemu plików.

Defragmentacja

Nie ma narzędzia do defragmentacji ext3 online , które działałoby na poziomie systemu plików. Istnieje defragmentator ext2 w trybie offline, e2defrag. Jednak e2defragmoże zniszczyć dane, w zależności od bitów funkcji włączonych w systemie plików; nie wie, jak obsłużyć wiele nowszych funkcji ext3.

Istnieją narzędzia do defragmentacji przestrzeni użytkownika, takie jak Shake i defrag. Shake działa, przydzielając miejsce dla całego pliku w ramach jednej operacji, co zwykle powoduje, że alokator znajdzie ciągłą przestrzeń dyskową. Jeśli istnieją pliki, które są używane w tym samym czasie, Shake spróbuje zapisać je obok siebie. Defrag działa poprzez kopiowanie każdego pliku nad sobą. Jednak ta strategia działa tylko wtedy, gdy system plików ma wystarczającą ilość wolnego miejsca. Prawdziwe narzędzie do defragmentacji nie istnieje dla ext3.

Jednak, jak stwierdza Przewodnik administratora systemu Linux: „Nowoczesne systemy plików Linux utrzymują fragmentację na minimalnym poziomie, utrzymując wszystkie bloki w pliku blisko siebie, nawet jeśli nie mogą być przechowywane w kolejnych sektorach. Niektóre systemy plików, takie jak ext3, efektywnie przydzielić wolny blok, który jest najbliższy innym blokom w pliku. Dlatego nie trzeba się martwić o fragmentację w systemie Linux."

Podczas gdy ext3 jest odporny na fragmentację plików, ext3 może z czasem ulec fragmentacji lub w przypadku określonych wzorców użytkowania, takich jak powolne pisanie dużych plików. W konsekwencji, ext4 (następca ext3) ma internetowy system plików do defragmentacji użytkową e4defrag i aktualnie obsługuje zakresów (regiony przyległe pliku).

Cofnij usunięcie

ext3 nie obsługuje odzyskiwania usuniętych plików. Sterownik ext3 aktywnie usuwa pliki, usuwając i-węzły plików ze względów bezpieczeństwa.

Wciąż istnieje kilka technik oraz darmowe i zastrzeżone oprogramowanie do odzyskiwania usuniętych lub utraconych plików przy użyciu analizy dziennika systemu plików; jednak nie gwarantują one żadnego konkretnego odzyskania plików.

Kompresja

e3compr to nieoficjalna łatka dla ext3, która wykonuje przezroczystą kompresję . Jest to bezpośredni port e2compr i nadal wymaga dalszego rozwoju. Dobrze się kompiluje i uruchamia z zewnętrznymi jądrami, ale księgowanie nie jest jeszcze zaimplementowane.

Brak obsługi migawek

W przeciwieństwie do wielu nowoczesnych systemów plików ext3 nie ma natywnej obsługi migawek , czyli możliwości szybkiego przechwytywania stanu systemu plików w dowolnym momencie. Zamiast tego opiera się na zajmujących mniej miejsca, migawkach na poziomie woluminów dostarczanych przez Linux LVM . System plików Next3 to zmodyfikowana wersja ext3, która oferuje obsługę migawek, ale zachowuje zgodność z formatem ext3 na dysku.

Brak sum kontrolnych w dzienniku

ext3 nie wykonuje sum kontrolnych podczas zapisywania do dziennika. Na urządzeniu pamięci masowej z dodatkową pamięcią podręczną, jeśli bariera=1 nie jest włączona jako opcja montowania (w /etc/fstab ) i jeśli sprzęt wykonuje buforowanie zapisu poza kolejnością, istnieje ryzyko poważnego uszkodzenia systemu plików podczas wypadek. Dzieje się tak, ponieważ urządzenia pamięci masowej z pamięciami podręcznymi zapisu zgłaszają systemowi, że dane zostały całkowicie zapisane, nawet jeśli zostały zapisane w (ulotnej) pamięci podręcznej.

Jeśli zapisy na dysku twardym są wykonywane poza kolejnością (ze względu na buforowanie zapisów w pamięci podręcznej nowoczesnych dysków twardych w celu amortyzacji prędkości zapisu), jest prawdopodobne, że zapisze się blok zatwierdzenia transakcji przed zapisaniem innych odpowiednich bloków. Jeśli awaria zasilania lub nieodwracalna awaria wystąpi przed zapisaniem innych bloków, system będzie musiał zostać ponownie uruchomiony. Po ponownym uruchomieniu system plików odtworzy dziennik w normalny sposób i odtworzy „zwycięzców” (transakcje z blokiem zatwierdzenia, w tym nieprawidłową transakcję powyżej, która została oznaczona prawidłowym blokiem zatwierdzenia). Powyższy zapis na niedokończony dysk będzie kontynuowany, ale z wykorzystaniem uszkodzonych danych dziennika. W ten sposób system plików omyłkowo nadpisze normalne dane uszkodzonymi danymi podczas odtwarzania dziennika. Gdyby użyto sum kontrolnych, w których bloki transakcji „fałszywego zwycięzcy” były oznaczone wzajemną sumą kontrolną, system plików mógłby wiedzieć lepiej i nie odtwarzać uszkodzonych danych na dysk. Suma kontrolna dziennika została dodana do ext4.

Systemy plików przechodzące przez interfejs mapowania urządzeń (w tym oprogramowanie RAID i implementacje LVM) mogą nie obsługiwać barier i będą wyświetlać ostrzeżenie, jeśli ta opcja montowania zostanie użyta. Istnieją również dyski, które nie implementują poprawnie rozszerzenia opróżniania pamięci podręcznej zapisu niezbędnego do działania barier, co powoduje podobne ostrzeżenie. W takich sytuacjach, w których bariery nie są obsługiwane lub praktyczne, niezawodna kolejność zapisu jest możliwa poprzez wyłączenie pamięci podręcznej zapisu dysku i użycie data=journalopcji montowania. Wyłączenie pamięci podręcznej zapisu dysku może być wymagane, nawet jeśli dostępne są bariery.

Aplikacje takie jak bazy danych oczekują, że wywołanie fsync() spowoduje opróżnienie oczekujących zapisów na dysk, a implementacja bariery nie zawsze czyści pamięć podręczną zapisu dysku w odpowiedzi na to wywołanie. Istnieje również potencjalny problem z implementacją bariery związany z obsługą błędów podczas zdarzeń, takich jak awaria dysku. Wiadomo również, że czasami niektóre technologie wirtualizacji nie przekazują poprawnie poleceń fsync lub flush do urządzeń bazowych (plików, woluminów, dysków) z systemu operacyjnego gościa. Podobnie, niektóre dyski twarde lub kontrolery implementują opróżnianie pamięci podręcznej niepoprawnie lub wcale, ale nadal reklamują, że jest obsługiwane i nie zwracają żadnego błędu, gdy jest używane. Jest tak wiele sposobów nieprawidłowej obsługi fsync i zapisu pamięci podręcznej, że bezpieczniej jest założyć, że opróżnianie pamięci podręcznej nie działa, o ile nie jest jawnie testowane, niezależnie od tego, jak wiarygodne są poszczególne komponenty.

Wymieranie bliskie czasu z powodu ograniczenia datownika

Ext3 przechowuje daty jako czas uniksowy, używając czterech bajtów w nagłówku pliku. 32 bity nie zapewniają wystarczającego zakresu, aby kontynuować przetwarzanie plików po 18 stycznia 2038 r. – problem roku 2038 . Oczekuje się, że to „Millennium Geeka” spowoduje powszechne zakłócenia, jeśli nie zostanie rozwiązane w odpowiednim czasie.

wew4

fsck zależność czasu od liczby i-węzłów (ext3 vs. ext4)
Główny artykuł: ext4

28 czerwca 2006 Theodore Ts'o , główny twórca ext3, ogłosił ulepszoną wersję, nazwaną ext4. 11 października 2008 r. łatki oznaczające ext4 jako kod stabilny zostały włączone do repozytoriów kodu źródłowego Linuksa 2.6.28, oznaczając koniec fazy rozwoju i zalecając jego przyjęcie. W 2008 r. Ts'o stwierdził, że chociaż ext4 ma ulepszone funkcje, takie jak bycie znacznie szybszym niż ext3, nie jest to duży postęp, wykorzystuje starą technologię i jest tymczasowym rozwiązaniem; Ts'o uważa, że Btrfs jest lepszym kierunkiem, ponieważ „oferuje ulepszenia w zakresie skalowalności, niezawodności i łatwości zarządzania”. Btrfs ma również „wiele tych samych pomysłów projektowych, które miał reiser3 / 4 ”.

Zobacz też

Bibliografia

Zewnętrzne linki