wew4

wew4
Deweloperzy Mingming Cao, Andreas Dilger, Alex Zhuravlev (Tomas), Dave Kleikamp, ​​Theodore Ts'o , Eric Sandeen, Sam Naghshineh i inni
Pełne imię i nazwisko Czwarty rozszerzony system plików
wprowadzony
  • Stabilny: 21 października 2008 r
  • Niestabilny: 10 października 2006 r
z Linuksem 2.6.28, 2.6.19
Identyfikator partycji 0x83 : MBR / EBR .



EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 : GPT Windows BDP . 0FC63DAF-8483-4772-8E79-3D69D8477DE4 : Dane systemu plików GPT Linux. 933AC7E1-2EB4-4F13-B844-0E14E2AEF915 : Partycja GPT /home.

3B8F8425-20E0-4F3B-907F-1A25A76F98E8 : Partycja GPT /srv (dane serwera).
Struktury
Zawartość katalogu Połączona lista , zaszyfrowane B-drzewo
Alokacja plików Zasięg / Bitmapa
Złe bloki Tabela
Granice
Maks. rozmiar woluminu 1 EIB
Maks. rozmiar pliku 16 TiB (dla rozmiaru bloku 4 lub 64 KiB)
Maks. liczba plików 4 miliardy (określone podczas tworzenia systemu plików)
Maks. długość nazwy pliku 255 bajtów
Dozwolone znaki w nazwach plików Wszystkie bajty oprócz NULL ('\0') i '/' oraz specjalnych nazw plików "." i „..”, które nie są zabronione, ale są zawsze używane w odpowiednim specjalnym celu.
Cechy
Zapisane daty modyfikacja (mtime), modyfikacja atrybutu (ctime), dostęp (atime), usuwanie (dtime), tworzenie (crtime)
Zakres dat 14 grudnia 1901 - 10 maja 2446
Rozdzielczość daty Nanosekunda
widelce NIE
Atrybuty acl, bh, bsddf, commit=nrsec, data=journal, data=ordered, data=writeback, delalloc, extends, journal_dev, mballoc, minixdf, noacl, nobh, nodelloc, noextents, nomballoc, nombcache, nouser_xattr, oldalloc, orlov , użytkownik_xattr
Uprawnienia systemu plików POSIX , POSIX ACL
Przezroczysta kompresja NIE
Przejrzyste szyfrowanie Tak
Deduplikacja danych NIE
Inny
Obsługiwane systemy operacyjne

ext4 ( czwarty rozszerzony system plików ) to system plików z księgowaniem dla Linuksa , opracowany jako następca ext3 .

ext4 był początkowo serią kompatybilnych wstecz rozszerzeń do ext3, z których wiele zostało pierwotnie opracowanych przez Cluster File Systems dla systemu plików Luster w latach 2003-2006, mających na celu rozszerzenie limitów pamięci i dodanie innych ulepszeń wydajności. Jednak inni jądra Linuksa sprzeciwiali się akceptowaniu rozszerzeń do ext3 ze względu na stabilność i zaproponowali rozwidlenie kodu źródłowego ext3, zmianę jego nazwy na ext4 i przeprowadzenie całego rozwoju tam, bez wpływu na istniejących użytkowników ext3. Propozycja ta została przyjęta i 28 czerwca 2006 Theodore Ts'o , opiekun ext3, ogłosił nowy plan rozwoju ext4.

Wstępna wersja rozwojowa ext4 została zawarta w wersji 2.6.19 jądra Linuksa. 11 października 2008 r. Łatki oznaczające ext4 jako stabilny kod zostały połączone w repozytoriach kodu źródłowego Linuksa 2.6.28, co oznacza koniec fazy rozwoju i zaleca przyjęcie ext4. Jądro 2.6.28, zawierające system plików ext4, zostało ostatecznie wydane 25 grudnia 2008 r. 15 stycznia 2010 r. Google ogłosił, że zaktualizuje swoją infrastrukturę pamięci masowej z ext2 do ext4. W dniu 14 grudnia 2010 r. Google ogłosił również, że będzie używać ext4 zamiast YAFFS w systemie Android 2.3 .

Przyjęcie

ext4 to domyślny system plików dla wielu dystrybucji Linuksa, w tym Debian i Ubuntu .

Cechy

Duży system plików
System plików ext4 obsługuje teoretycznie woluminy o rozmiarach do 64 zebibajtów (ZiB) i pojedyncze pliki o rozmiarach do 16 tebibajtów (TiB) przy standardowym rozmiarze bloku 4 KiB oraz woluminy o rozmiarach do 1 yobibajta (YiB ) z klastrami 64 KiB , chociaż ograniczenie formatu ekstentów sprawia, że ​​praktycznym ograniczeniem jest 1 eksbibajt (EiB) . Maksymalne limity rozmiaru pliku, katalogu i systemu plików rosną co najmniej proporcjonalnie do rozmiaru bloku systemu plików do maksymalnego rozmiaru bloku 64 KiB dostępnego w procesorach ARM i PowerPC / Power ISA .
Zasięgi
Zasięgi zastępują tradycyjny schemat mapowania bloków używany przez ext2 i ext3. Zakres to szereg ciągłych bloków fizycznych, poprawiających wydajność dużych plików i zmniejszających fragmentację. Pojedynczy zasięg w ext4 może mapować do 128 MiB ciągłej przestrzeni z rozmiarem bloku 4 KiB. W i-węźle mogą być przechowywane cztery ekstenty . Jeśli plik zawiera więcej niż cztery zakresy, pozostałe zakresy są indeksowane w postaci drzewa .
Kompatybilność wsteczna
ext4 jest wstecznie kompatybilna z ext3 i ext2 , umożliwiając montowanie ext3 i ext2 jako ext4. Poprawi to nieznacznie wydajność, ponieważ niektóre nowe funkcje implementacji ext4 mogą być również używane z ext3 i ext2, takie jak nowy algorytm alokacji bloków, bez wpływu na format dysku.
ext3 jest częściowo kompatybilny w przód z ext4. Praktycznie ext4 nie będzie montowany jako system plików ext3 po wyjęciu z pudełka, chyba że niektóre nowe funkcje zostaną wyłączone podczas jego tworzenia, takie jak ^extent , ^flex_bg , ^huge_file , ^uninit_bg , ^dir_nlink i ^extra_isize .
Trwała alokacja wstępna
ext4 może wstępnie alokować miejsce na dysku dla pliku. Aby to zrobić w większości systemów plików, podczas tworzenia pliku byłyby zapisywane zera. W ext4 (i niektórych innych systemach plików, takich jak XFS ) fallocate() może być użyte nowe wywołanie systemowe w jądrze Linuksa. Przydzielona przestrzeń byłaby gwarantowana i prawdopodobnie ciągła. Ta sytuacja ma zastosowania do strumieniowego przesyłania multimediów i baz danych.
Opóźniona alokacja
ext4 wykorzystuje technikę wydajności zwaną allocate-on-flush , znaną również jako alokacja opóźniona . Oznacza to, że ext4 opóźnia alokację bloków do czasu usunięcia danych na dysk; w przeciwieństwie do tego, niektóre systemy plików przydzielają bloki natychmiast, nawet jeśli dane trafiają do pamięci podręcznej zapisu. Opóźniona alokacja poprawia wydajność i zmniejsza fragmentację , skutecznie przydzielając jednocześnie większe ilości danych.
Nieograniczona liczba podkatalogów
ext4 nie ogranicza liczby podkatalogów w jednym katalogu, z wyjątkiem nieodłącznego limitu rozmiaru samego katalogu. (W ext3 katalog może mieć co najwyżej 32 000 podkatalogów.) Aby umożliwić większe katalogi i ciągłą wydajność, ext4 w Linuksie 2.6.23 i nowszych domyślnie włącza indeksy HTree (wyspecjalizowana wersja B-drzewa ), co pozwala katalogom do około 10–12 milionów wpisów do przechowywania w 2-poziomowym indeksie HTree i 2 GB limitu rozmiaru katalogu dla rozmiaru bloku 4 KiB, w zależności od długości nazwy pliku. W Linuksie 4.12 i nowszych largedir umożliwiła 3-poziomowe HTree i rozmiary katalogów powyżej 2 GB, pozwalając na około 6 miliardów wpisów w jednym katalogu.
Sumy kontrolne dziennika
ext4 używa sum kontrolnych w dzienniku w celu zwiększenia niezawodności, ponieważ dziennik jest jednym z najczęściej używanych plików na dysku. Ta funkcja ma dodatkową zaletę: pozwala bezpiecznie uniknąć oczekiwania na operacje we/wy dysku podczas kronikowania, nieznacznie poprawiając wydajność. Sumy kontrolne dziennika zostały zainspirowane artykułem badawczym z University of Wisconsin , zatytułowanym IRON File Systems (konkretnie, sekcja 6, zwana „sumami kontrolnymi transakcji”), z modyfikacjami w ramach implementacji złożonych transakcji wykonywanych przez system plików IRON (pierwotnie zaproponowany przez Sama Naghshineh na szczycie RedHat).
Sumy kontrolne metadanych
Od wydania jądra Linuksa 3.5 w 2012 roku
Szybsze sprawdzanie systemu plików
W ext4 nieprzydzielone grupy bloków i sekcje tablicy i-węzłów są oznaczone jako takie. Dzięki temu e2fsck może je całkowicie pominąć i znacznie skraca czas sprawdzania systemu plików. Linux 2.6.24 implementuje tę funkcję.
fsck od liczby i-węzłów ( ext3 vs. ext4)
Alokator multibloków
Kiedy ext3 dołącza do pliku, wywołuje alokator bloków, raz dla każdego bloku. W rezultacie, jeśli istnieje wiele współbieżnych programów zapisujących, pliki na dysku mogą łatwo ulec fragmentacji . Jednak ext4 wykorzystuje opóźnioną alokację, co pozwala na buforowanie danych i przydzielanie grup bloków. W rezultacie alokator wieloblokowy może dokonywać lepszych wyborów dotyczących ciągłej alokacji plików na dysku. Alokator multibloków może być również używany, gdy pliki są otwierane w trybie O_DIRECT. Ta funkcja nie ma wpływu na format dysku.
Ulepszone sygnatury czasowe
W miarę jak komputery stają się ogólnie szybsze, a system Linux jest coraz częściej wykorzystywany w aplikacjach o znaczeniu krytycznym , szczegółowość sygnatur czasowych opartych na sekundach staje się niewystarczająca. Aby rozwiązać ten problem, ext4 zapewnia znaczniki czasu mierzone w nanosekundach . Ponadto 2 bity rozszerzonego pola znacznika czasu są dodawane do najbardziej znaczących bitów pola sekund znaczników czasu, aby odroczyć problem roku 2038 o dodatkowe 408 lat.
ext4 dodaje również obsługę znaczników czasowych czasu utworzenia. Ale, jak Theodore Ts'o , chociaż łatwo jest dodać dodatkowe pole daty utworzenia w i-węźle (w ten sposób technicznie umożliwiając obsługę tych znaczników czasu w ext4), trudniej jest zmodyfikować lub dodać niezbędne wywołania systemowe , jak stat() (co prawdopodobnie wymagałoby nowej wersji) i różnych bibliotek , które od nich zależą (jak glibc ). Zmiany te będą wymagały koordynacji wielu projektów. Dlatego data utworzenia przechowywana przez ext4 jest obecnie dostępna tylko dla programów użytkownika w systemie Linux za pośrednictwem statx() .
Przydziały projektów
Obsługa przydziałów projektów została dodana w jądrze Linuksa 4.4 8 stycznia 2016 r. Ta funkcja umożliwia przypisanie limitów przydziałów dysku do określonego identyfikatora projektu. Identyfikator projektu pliku to 32-bitowa liczba przechowywana w każdym pliku i jest dziedziczona przez wszystkie pliki i podkatalogi utworzone w katalogu nadrzędnym z przypisanym identyfikatorem projektu. Pozwala to na przypisanie limitów przydziału do określonego drzewa podkatalogów niezależnie od uprawnień dostępu do pliku, takich jak przydziały użytkowników i projektów, które są zależne od UID i GID. Chociaż jest to podobne do przydziału katalogu, główna różnica polega na tym, że ten sam identyfikator projektu można przypisać do wielu katalogów najwyższego poziomu i nie jest on ściśle hierarchiczny.
Szyfrowanie przezroczyste
Obsługa szyfrowania przezroczystego została dodana w jądrze Linuksa 4.1 w czerwcu 2015 r.
Leniwa inicjalizacja
Funkcja lazyinit umożliwia czyszczenie tablic i-węzłów w tle, przyspieszając inicjalizację podczas tworzenia nowego systemu plików ext4. Jest dostępny od 2010 roku w jądrze Linuksa w wersji 2.6.37.
Bariery zapisu
ext4 domyślnie włącza bariery zapisu. Zapewnia, że ​​metadane systemu plików są poprawnie zapisywane i uporządkowane na dysku, nawet gdy pamięć podręczna zapisu traci moc. Wiąże się to z kosztami wydajności, zwłaszcza w przypadku aplikacji, które intensywnie korzystają z fsync lub tworzą i usuwają wiele małych plików. W przypadku dysków z pamięcią podręczną zapisu podtrzymywaną bateryjnie wyłączenie barier (opcja „bariera=0”) może bezpiecznie poprawić wydajność.

Ograniczenia

W 2008 roku główny twórca systemów plików ext3 i ext4, Theodore Ts'o , stwierdził, że chociaż ext4 ma ulepszone funkcje, nie jest to duży postęp, wykorzystuje starą technologię i stanowi lukę. Ts'o uważa, że ​​Btrfs to lepszy kierunek, ponieważ „oferuje poprawę skalowalności, niezawodności i łatwości zarządzania”. Btrfs ma również „wiele takich samych pomysłów projektowych, jakie reiser3 / 4 ”. Jednak ext4 nadal zyskuje nowe funkcje, takie jak szyfrowanie plików i sumy kontrolne metadanych.

System plików ext4 nie honoruje atrybutu pliku „bezpieczne usuwanie” , który ma powodować nadpisywanie plików po usunięciu. W 2011 roku zaproponowano poprawkę implementującą bezpieczne usuwanie, ale nie rozwiązała ona problemu trafiania poufnych danych do dziennika systemu plików.

Opóźniona alokacja i potencjalna utrata danych

Ponieważ opóźniona alokacja zmienia zachowanie, na którym polegali programiści w przypadku ext3, ta funkcja stwarza dodatkowe ryzyko utraty danych w przypadku awarii systemu lub utraty zasilania, zanim wszystkie dane zostaną zapisane na dysku. Z tego powodu ext4 w wersjach jądra 2.6.30 i późniejszych automatycznie obsługuje takie przypadki, tak jak robi to ext3.

Typowym scenariuszem, w którym może się to zdarzyć, jest program zastępujący zawartość pliku bez wymuszania zapisu na dysku za pomocą fsync . Istnieją dwa popularne sposoby zastępowania zawartości pliku w systemach Unix:

  • fd= otwórz ("plik", O_TRUNC); write(fd, dane); zamknij(fd);
W takim przypadku istniejący plik jest obcinany w momencie otwierania (ze względu na flagę O_TRUNC ), a następnie wypisywane są nowe dane. Ponieważ zapis może zająć trochę czasu, istnieje możliwość utraty zawartości nawet w przypadku ext3, ale zwykle bardzo mała. Ponieważ jednak ext4 może długo opóźniać zapisywanie danych pliku, ta możliwość jest znacznie większa.
Istnieje kilka problemów, które mogą się pojawić:
  1. Jeśli zapis się nie powiedzie (co może być spowodowane błędami w programie zapisującym lub warunkami zewnętrznymi, takimi jak zapełniony dysk), wówczas zarówno oryginalna, jak i nowa wersja pliku zostaną utracone, a plik może być uszkodzony, ponieważ napisano tylko jego część.
  2. Jeśli inne procesy uzyskują dostęp do pliku podczas jego zapisywania, widzą uszkodzoną wersję.
  3. Jeśli inne procesy mają otwarty plik i nie spodziewają się zmiany jego zawartości, procesy te mogą ulec awarii. Jednym godnym uwagi przykładem jest plik biblioteki współdzielonej, który jest mapowany na uruchomione programy.
Z powodu tych problemów często preferowany jest następujący idiom zamiast powyższego:
  • fd=open("plik.nowy"); write(fd, dane); zamknij(fd); zmień nazwę ("plik.nowy", "plik");
Tworzony jest nowy plik tymczasowy ("file.new"), który początkowo zawiera nową zawartość. Następnie nazwa nowego pliku zostanie zastąpiona starą. Zastępowanie plików przez rename() gwarantuje atomową zgodność ze standardami POSIX – tzn. albo stary plik pozostaje, albo jest zastępowany nowym. Ponieważ domyślny „uporządkowany” tryb kronikowania ext3 gwarantuje, że dane pliku są zapisywane na dysku przed metadanymi, ta technika gwarantuje, że albo stara, albo nowa zawartość pliku zostanie zachowana na dysku. Opóźniona alokacja ext4 łamie to oczekiwanie, ponieważ zapis pliku może być opóźniony przez długi czas, a zmiana nazwy jest zwykle przeprowadzana, zanim nowa zawartość pliku dotrze na dysk.

Częstsze używanie fsync() w celu zmniejszenia ryzyka dla ext4 może prowadzić do spadku wydajności w systemach plików ext3 montowanych z flagą data=ordered (domyślnie w większości dystrybucji Linuksa). Biorąc pod uwagę, że oba systemy plików będą używane przez jakiś czas, komplikuje to sprawy dla twórców aplikacji dla użytkowników końcowych. W odpowiedzi ext4 w jądrach Linuksa 2.6.30 i nowszych wykrywa występowanie tych typowych przypadków i wymusza natychmiastowe przydzielenie plików. Przy niewielkim koszcie wydajności zapewnia to semantykę podobną do trybu uporządkowanego ext3 i zwiększa szansę, że którakolwiek wersja pliku przetrwa awarię. To nowe zachowanie jest domyślnie włączone, ale można je wyłączyć za pomocą opcji montowania „noauto_da_alloc”.

Nowe łatki stały się częścią głównego jądra 2.6.30, ale różne dystrybucje zdecydowały się przenieść je do wersji 2.6.28 lub 2.6.29.

Te poprawki nie zapobiegają całkowicie potencjalnej utracie danych ani nie pomagają w ogóle z nowymi plikami. Jedynym sposobem na zapewnienie bezpieczeństwa jest pisanie i używanie oprogramowania, które wykonuje funkcję fsync() , gdy jest to konieczne. Problemy z wydajnością można zminimalizować, ograniczając kluczowe zapisy na dysku, które wymagają rzadszego wykonywania funkcji fsync() .

Realizacja

Uproszczona struktura jądra Linuksa: ext4 jest zaimplementowane pomiędzy wirtualnym systemem plików jądra Linuksa a ogólną warstwą bloków.

Wirtualny system plików jądra Linuksa to podsystem lub warstwa wewnątrz jądra Linuksa. Jest to wynik bardzo poważnej próby zintegrowania wielu systemów plików w uporządkowaną pojedynczą strukturę. Kluczową ideą, której początki sięgają pionierskiej pracy wykonanej przez pracowników Sun Microsystems w 1986 roku, jest wyabstrahowanie tej części systemu plików, która jest wspólna dla wszystkich systemów plików, i umieszczenie tego kodu w osobnej warstwie, która wywołuje bazowy konkretny plik systemów do faktycznego zarządzania danymi.

Wszystkie wywołania systemowe związane z plikami (lub pseudoplikami) są kierowane do wirtualnego systemu plików jądra Linuksa w celu wstępnego przetworzenia. Te wywołania, pochodzące z procesów użytkownika, to standardowe wywołania POSIX, takie jak open , read , write , lseek itp.

Zgodność z systemami Windows i Macintosh

Obecnie ext4 ma pełne wsparcie dla systemów operacyjnych innych niż Linux.

Windows może uzyskać dostęp do ext4 od Windows 10 Insider Preview Build 20211. Jest to możliwe dzięki podsystemowi Windows dla systemu Linux (WSL), który został wprowadzony wraz z rocznicową aktualizacją systemu Windows 10 (wersja 1607) 2 sierpnia 2016 r. WSL jest dostępny tylko w wersjach 64-bitowych Windows 10 od wersji 1607. Jest również dostępny w systemie Windows Server 2019. Duże zmiany w architekturze WSL nastąpiły wraz z wydaniem WSL 2 12 czerwca 2019 r. WSL 2 wymaga systemu Windows 10 w wersji 1903 lub nowszej, z kompilacją 18362 lub nowszą, dla systemów x64 i wersji 2004 lub nowszej, z kompilacją 19041 lub nowszą, dla systemów ARM64.

Paragon oferuje swój komercyjny produkt Linux File Systems for Windows, który umożliwia odczyt/zapis dla ext2/3/4 w systemach Windows 7 SP1/8/8.1/10 i Windows Server 2008 R2 SP1/2012/2016.

macOS ma pełną zdolność odczytu i zapisu ext2/3/4 za pośrednictwem extFS for Mac firmy Paragon Software, która jest produktem komercyjnym. Darmowe oprogramowanie, takie jak ext4fuse, obsługuje tylko odczyt z ograniczoną funkcjonalnością.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Ext4&oldid=1136343965 ”