Ubuntu.pl 🇺🇦️W związku z niedawną premierą jądra w wersji 2.6.28, zawierającego obsługę nowego systemu plików ext4, Canonical poinformowało o planach wprowadzenia go do kwietniowej edycji Ubuntu, Jaunty Jackalope. Nieobeznanemu w temacie czytelnikowi łatwo jest pogubić się w atmosferze gorących dyskusji o niezawodności nowinki oraz w gąszczu testów wydajności w porównaniu z popularnymi, obecnie używanymi systemami plików. Ten felieton stawia sobie szczytny cel przybliżenia laikom technicznej strony tego kamienia milowego w rozwoju systemu GNU/Linux.
Ekstenty
Używany system plików determinuje sposób, w jaki system operacyjny może zapisać plik na dysku. ext3 na ten przykład używa mechanizmu blokowego — plik o wielkości 100 megabajtów zostanie zapisany jako 256 tysięcy bloków (o wielkości 4 kilobajtów każdy); ale im więcej danych zawiera się w pliku, tym więcej bloków zostanie użytych. To wprowadza konieczność posługiwania się olbrzymią ilością bloków, co w efekcie obniża wydajność.
Dzisiejsze zastosowania komputerów nie wykluczają plików o znacznie większych objętościach niż w przytoczonym przykładzie. Dla takich danych monstrualnych rozmiarów metoda blokowa przestaje być efektywna. Twórcy ext4 znaleźli na to radę i wprowadzili pojęcie ekstentów (ang. extents) — mechanizmu przydzielania miejsca dla tworzonych danych. W jaki sposób? Rozwinięciem metody blokowej, która od teraz grupuje bloki położone fizycznie koło siebie.
Gdzie tutaj obiecana rewolucja? Przy zastosowaniu ext4 polecenie zapisu naszego przykładowego pliku o wielkości 100 megabajtów będzie brzmiało „zapisz dane w n kolejnych blokach”, miast podawać z osobna każdy blok (jego numer bądź adres). Metoda stosowania w ext4 potrafi łączyć do 128 megabajtów danych, czego efektem dla pliku jednogigabajtowego jest wykonanie mapowania danych na zaledwie 10 połączonych obszarów (ekstentów), zamiast na 256 tysięcy bloków. Zysk wydajności widać tu gołym okiem, ale metoda ta pozwala także zmniejszyć fragmentację zapisanych danych.
Alokacja wielu bloków
No dobrze, być może nie wystarczy gołe oko, żeby zobaczyć, skąd się ten wzrost wydajności bierze. Ale spieszę wyjaśnić: ext3 używa mechanizmu alokacji bloków, który potrafi operować tylko na pojedynczym bloku. To oznacza, że zapisanie (mapowanie danych na logiczną strukturę dysku) stumegabajtowego pliku z początku artykułu wymaga wywołania procedury alokacji aż 25600 razy! Co więcej, sam alokator nie jest w stanie w żaden sposób zoptymalizować swojej pracy — nie wie przecież, jak wiele danych przyjdzie mu zapisać (czyli ile bloków jeszcze przydzielić).
ext4 i na to ma radę. Jego mechanizm alokacji jest sprytniejszy, ponieważ potrafi naraz zająć się większą ilością bloków, co zmniejsza w efekcie liczbę jego koniecznych wywołań.
Kompatybilność
Nie mniej ważną cechą nowego systemu plików jest jego kompatybilność z poprzednikami. Został tak opracowany, by łatwo można było zacząć go używać na istniejących systemach rodziny ext3, wykluczając potrzebę formatowania partycji, którymi ma zarządzać.
Defragmentacja
Chociaż — jak wspomniano wyżej — ext4 ma za zadanie zmniejszyć ilość danych ulegających fragmentacji, to nie można przecież całkowicie wyeliminować tego zjawiska. Twórcy pomyśleli i o tym: dostępne będzie narzędzie pozwalające w locie defragmentować tak pojedyncze pliki, jak i całe struktury katalogów. Tego bajeru jeszcze nie ma w jądrze serii 2.6.28, ale już niedługo…
Co jeszcze…?
Co dodatkowo oferuje ext4? Szybsze sprawdzenie poprawności systemu plików dzięki pominięciu w tym procesie nieużywanych bloków. Prawda, że proste? Do tego dochodzi jeszcze dokładniejsza metoda zapisu czasu (z rozdzielczością aż do nanosekundy) oraz ominięcie Problemu Roku 2038 (*) 🙂
Co więcej, wolumeny używające ext4 mogą posiadać nieograniczoną liczbę podkatalogów (starszy brat, ext3, oferował „jedynie” 32 tysiące). Na koniec perełka: te podkatalogi możemy zakładać sobie na wolumenach o pojemności aż do eksabajta (2^60 bajtów), a w nich trzymać pliki o rozmiarach nie przekraczających 16 terabajtów. Ot i drobnostka… 🙂
(*) Wtedy wyczerpie się liczba sekund, które upłynęły od początku tzw. Epoki (ang. Epoch), czyli czas mierzony od północy dnia 1 stycznia 1970, a wyrażony w postaci 32-bitowej liczby. Jest to obecnie przyjmowany standard zapisu czasu. ext4 dodaje dwa bity do tej wartości i pozwala przez to opisać zakres dłuższy o ponad pół milenium!
Wydajność
Serwis Phoronix przeprowadził niedawno testy porównawcze ext4 i jego współczesnej konkurencji: ext3, XFS, JFS i ReiserFS. Najbardziej znacząca zaleta nowego dziecka programistów jądra ujawniła się przy zapisie pliku o rozmiarach 4 gigabajtów. ext4 był w tym dwukrotnie szybszy!
O dalsze testy pokusili się włodarze Softpedii. Tutaj ext4 pokazał klasę nie tylko w operacjach odczytu, ale pozwolił zredukować czas uruchamiania systemu (który nigdy nie jest zbyt krótki). Oto fragment osiągniętych rezultatów:
Ubuntu 8.10 z systemem plików EXT3 startuje w 31.8 sekundy
(na procesorze AMD Sempron);Ubuntu 9.04 Alpha (Build 20090112.1) z systemem plików EXT3 startuje w 28.3 sekundy
(na procesorze AMD Sempron);Ubuntu 9.04 Alpha (Build 20090112.1) z systemem plików EXT4 startuje w 23.1 sekundy
(na procesorze AMD Sempron).Ubuntu 8.10 z systemem plików EXT3 startuje w 26.8 sekund
(na procesorze Intel Core 2 Duo);Ubuntu 9.04 Alpha (Build 20090112.1) z systemem plików EXT3 startuje w 24.5 sekundy
(na procesorze Intel Core 2 Duo);Ubuntu 9.04 Alpha (Build 20090112.1) z systemem plików EXT4 startuje w 21.4 sekundy (sic!)
(na procesorze Intel Core 2 Duo)
Autor: Rami Taibah
Tłumaczenie na podstawie: Ext4 Filesystem Explained in Plain English
A czy wiadomo już jak można przejść z ext3 na ext4? Jest jakieś prawbopodobieństwo utraty danych?
Nie wiem jak to zrobić.
[quote post=”3977″]Wtedy wyczerpie się liczba sekund, które upłynęły od początku tzw. Epoki (ang. Epoch), czyli czas mierzony od północy dnia 1 stycznia 1970, a wyrażony w postaci 32-bitowej liczby. Jest to obecnie przyjmowany standard zapisu czasu. ext4 dodaje dwa bity do tej wartości i pozwala przez to opisać zakres dłuższy o ponad pół milenium![/quote]
Obawiam się, że nie kapuje. Dodając 2 bity można zwiększyć zakres czasu czterokrotnie. Z problemu roku 2038 zrobi się problem roku 2242. No chyba, że dodano 3 bity (2 extra oraz ostatni bit z 32 bitów ponieważ tak naprawdę ext3 wykorzystywał 31 bitów). Wtedy rzeczywiście odsuniemy problem o ponad pół milenium do roku 2504. Wszystko to jednak pikuś przy problemie roku 10000 😉
świetny artykuł!
szkoda ze brakuje porownia z ext2 , w niektorych zastosowaniach jest to nadal najszybszy FS
@Kazislav
Migracja z ext3 na ext4 jest wyjątkowo bezbolesna [1], nie wiem jednak jak ma się sprawa z bezpieczeństwem danych.
1. http://kernelnewbies.org/Ext4#head-3891522e0601162aab24c73c1f148a1e28c6a9d4
Artykuł ciekawy. Kilka błędów by się znalazło, ale ja nie o tym.
Interesuje mnie problem fragmentacji. Strasznie mnie bawi, gdy czytam, że ext3 nie wymaga defragmentowania. Tu to samo, ale już że „będzie zaimplementowane później defragmentowanie w locie”. Zjawisko fragmentacji wygląda tak:
Dyski mamy o ograniczonej pojemności, póki co. Instalujemy system, jakiś soft, co zajmuje miejsce. Fragmentacji póki co brak (co już jest nieprawdą, bo pliki tymczasowe, które już zajęły katalog /tmp właśnie zwolniły miejsce, ale przyjmijmy, że ich nie było i nie ma). Resztę dysku zapełniamy np. empetrójkami (a co, wolno nam). I teraz przychodzi moment na pobranie pliku ubuntu_9.04.iso , na co potrzebujemy 700MB. Trzeba albo odinstalować jakiś soft lub empetrójki. Jako, że soft jest nam niezbędny, kasujemy 700MB empetrójek, tych najrzadziej słuchanych. I pojawia się problem, bo MP3 mają po 5MB, czyli kasujemy względnie losowo 140 plików. Reszta pozostaje nieruszona. No i co? Mamy nasze 700MB wolnego ale ono nie jest jednym ciągiem wolnego miejsca na dysku i na mój chłopski rozum nigdy nie będzie… Niby jak? Jądro zajmie się „szybciutkim” przeniesieniem empetrójek tak, że dostaniemy ciągłe 700MB? No żart jakiś… Gdyby MP3 miały *dokładnie* 5MB to pewnie pół biedy, ale tak przecież nie jest i próba szybkiego zrobienia ciągłych 700MB przez szybkie zdefragmentowanie samego obszaru MP3 spowoduje jeszcze większą fragmentację empetrójek. No proszę o wytłumaczenie tak na chłopski rozum.
w niektórych zastosowaniach to i windows jest najszybszy 😉
A próbował ktoś ustawić datę na 2038 (z tego co kiedyś wyliczyłem to chyba 19 stycznia)? Ja ustawiłem i było coś w stylu „CPU overload, aborting…” 😛 Wszystko zachowywało się jakoś dziwnie i wogóle. Ale to już chyba taki komputer.
Bzyk, masz rację – cudów nie ma. Z tą fragmentacją chodzi o to, że zaleca się zostawienie sobie zapasu wolnego miejsca i nie zapełnianie dysku do końca. Wtedy system stara się upychać małe pliki w zwolnione dziury, a dużych nie.
Jak ostatnio robiłem sprawdzenie dysku za pomocą fsck to wykazało mi 3.3% nieciągłych plików. To nie jest dużo, a dysk zapełniłem do końca parę razy.
Może ktoś wie, jak by to wyglądało gdyby dodać do testu ZFS i NTFS?
@Bzyk
http://blog.brodowski.net.pl/2007/11/20/dlaczego-defragmentacja-dysku-pod-linuksem-nie-jest-potrzebna/
Oczywiście w ext4 można stosować jakieś algorytmy przestawiania dwóch bloków, aby zachować ciągłość plików. Bloki można indeksować, sprawdzać odległości między nimi. Systemy plików zachowują się dobrze jeżeli nie zapełnia ich się po brzegi (rzędu 95% i wyżej). Wtedy mechanizmy działające przeciwko fragmentacji działają bardzo dobrze, później jest to fizyczne trudne 😉
Przykładowo mój ext3, który przez pewien czas był zapełniony w 94-98% posiada poziom fragmentacji rzędu 5%. Używany system od dwóch lat, nie przeszedł nigdy defragmentacji…
[16498 non-contiguous inodes (5.0%)]
Zobaczymy jak to wyjdzie w praniu. Bo jak na razie w duzych rozwiazaniach niepokonanym liderem jest XFS.
ext4 również sobie rezerwuje domyślnie 5% miejsca co przy dużych dyskach jest wartością dużą?
Ale tak czytam komentarze i może to nawet dobrze, bo system mając coś porezerwowanego miejsca poradzi sobie lepiej z prooblemem fragmentacji?
Interesuje mnie jak wygląda kwestia dalszego rozwoju ext4. Ktoś kto zaczął używać ext4 jeszcze w fazie rozwojowej i teraz korzysta z wersji stabilnej (2.6.28 i nowsze) nie wykorzystuje w pełni możliwości ext4. Musi dokonać formatowania.
Czy takie zmiany, które będą wymagały ponownego formatowania jeszcze nam grożą?
Bardzo dobry artykuł, przybliża właściwości nowego systemu plików, który sam w sobie jest bardzo obiecujący – zwłaszcza, że można bezboleśnie przejść z ext3 -> ext4 …
Bardzo mnie interesuje kwestia odzyskiwania skasowanych danych na partycji ext4. Z tego co wiem na ext3 jaki kolwiek odzysk (po formacie lub zwykłym skasowaniu) był prawie niemożliwy. Nie znam się na tym dokładnie, ale czy ktoś jest w stanie się na ten temat wypowiedzieć?
Owszem, ext3 i ext4 są kompatybilne, ale nie można wtedy używać extents.
Super artykuł. Dziwią mnie tylko wyniki testów prędkości. Kiedyś wykonałem kompleksowe testy systemów plików (~3 miesiące badań non stop) i zrobiłem system ekspertowy, który w zależności od dobranych parametrów wybierał odpowiedni system plików do potrzeb. Porównałem prędkość działania i implementację dla jąder 2.4 i 2.6. Wyniki wskazują tutaj na testy na jądrze 2.4. Ja używałem przy testach bonnie . Najszybszym systemem plików okazał się ext2 🙂 a potem ext3, ale obciążenie procka było 40% (oczywiście jeszcze wszystko zależy od rozmiaru bloków i operacji które wykonujemy — kopiowanie plików do 1MB i powyżej 4G). XFS okazał się beznadziejny przy 2.6 co mnie strasznie zdziwiło. Moim zdaniem nalepiej wypadł jfs, który najmniej obciążał CPU (w granicach 6% przy każdej operacji, a z prędkością odczytu i zapisu był w ścisłej czołówce). Jestem ciekaw jak to się przedstawia przy ext4. Ja właśnie na ten system przeszedłem na jednej swojej maszynce. Nie jestem w stanie nic powiedzieć na temat działania, bo nie wiem czy 9.04 alpha3 tak przyspieszyło czy wydajność wzrosła przez system plików. Ryzyk fizyk 🙂 maszynka nie ważna 🙂 ważne ciary na plerach podczas zabawy 🙂 i jak coś się wiochnie.
Pytanie, co to za wredna mania używania spolszczonych słów angielskich, kiedy „extent” pięknie przekłada się na „zakres”?
photorec odzyska skasowane pliki z ext3 bez problemu
[quote comment=”35749″]Pytanie, co to za wredna mania używania spolszczonych słów angielskich, kiedy „extent” pięknie przekłada się na „zakres”?[/quote]
inglisz jest trendy/jazzy. Zwlaszcza wsrod ekspertow.
[quote comment=”35832″][quote comment=”35749″]Pytanie, co to za wredna mania używania spolszczonych słów angielskich, kiedy „extent” pięknie przekłada się na „zakres”?[/quote]
inglisz jest trendy/jazzy. Zwlaszcza wsrod ekspertow.[/quote]
Ha! Pytanie, czy owe „zakresy” weszły do nomenklatury technicznego języka w kontekście systemu plików? Jeśli tak, to mea culpa i biję się w piersi 🙂
A mnie coś podkusiło i home mam na xfs. W razie chęci przejścia na ext4 czeka mnie trochę zabawy. 🙂
XFS nie jest zły, ale kasowanie wielu dużych plików trwa lata, co jest trochę denerwujące.
Cześć Gawiedzi
Czy ext4 obsługuje większe bloki niż 4kb (górna granica w ext3)?
Co do zarządzania extend-ami to większość systemów plików klasy Enterprise to zawsze robiła. Bo ja wiadomo alokację bloków lepiej robić dla większej ilości bloków tak aby zawsze minimalizować ilość operacji IO, której koszt jest zawsze podobny bez względy na wielkość zapisywaną / odczytywaną.
Czy ext4 jest już stabilny?
[quote comment=”35681″]Artykuł ciekawy. Kilka błędów by się znalazło, ale ja nie o tym.
Interesuje mnie problem fragmentacji. Strasznie mnie bawi, gdy czytam, że ext3 nie wymaga defragmentowania. Tu to samo, ale już że „będzie zaimplementowane później defragmentowanie w locie”. Zjawisko fragmentacji wygląda tak:
Dyski mamy o ograniczonej pojemności, póki co. Instalujemy system, jakiś soft, co zajmuje miejsce. Fragmentacji póki co brak (co już jest nieprawdą, bo pliki tymczasowe, które już zajęły katalog /tmp właśnie zwolniły miejsce, ale przyjmijmy, że ich nie było i nie ma). Resztę dysku zapełniamy np. empetrójkami (a co, wolno nam). I teraz przychodzi moment na pobranie pliku ubuntu_9.04.iso , na co potrzebujemy 700MB. Trzeba albo odinstalować jakiś soft lub empetrójki. Jako, że soft jest nam niezbędny, kasujemy 700MB empetrójek, tych najrzadziej słuchanych. I pojawia się problem, bo MP3 mają po 5MB, czyli kasujemy względnie losowo 140 plików. Reszta pozostaje nieruszona. No i co? Mamy nasze 700MB wolnego ale ono nie jest jednym ciągiem wolnego miejsca na dysku i na mój chłopski rozum nigdy nie będzie… Niby jak? Jądro zajmie się „szybciutkim” przeniesieniem empetrójek tak, że dostaniemy ciągłe 700MB? No żart jakiś… Gdyby MP3 miały *dokładnie* 5MB to pewnie pół biedy, ale tak przecież nie jest i próba szybkiego zrobienia ciągłych 700MB przez szybkie zdefragmentowanie samego obszaru MP3 spowoduje jeszcze większą fragmentację empetrójek. No proszę o wytłumaczenie tak na chłopski rozum.[/quote]
Bzyk: z tego co zrozumiałem to zysk wydajności będzie wynikał ze sposobu adresowania bloków. Jak jedna mp3ójka zwolni Ci te 3MB, to ext4 zapisze tam 768x4kB jako jakąś-tam cześć dużego pliku, a pozostałe jego części zostaną zapisane w innym miejscu. Różnica polega na tym że te 768x4Kb zostaną zapisane w wydajniejszy sposób niż w starszych extach, bo jak wyczytałem z artykułu, zostanie naraz zaadresowanych wszystkich 768blokow na raz, a nie każdy z osobna. Ale to tylko tak mi się wydaje ja się nie znam 😀
pozdrawiam
No to ja dorzucę jeszcze mój wynik z bootcharta – bez wyłączania usług, system postawiony niedawno na ext4, /home na ext3, zainstalowane mpd i lamp w usługach startowych. Start Ubuntu 9.04 – 18 sekund. Sprzęt: E2140@3,2GHz, MSI P35-Neo2 FR, WD 3200AAKS.
A ja zainstalowałem kubuntu 9.04 na ext4 i niestety system mi się zawieszał, wiec wróciłem szybko do ext3 i wszystko działa ok.
[quote post=”3977″]Metoda stosowania w ext4 potrafi łączyć do 128 megabajtów danych, czego efektem dla pliku jednogigabajtowego jest wykonanie mapowania danych na zaledwie 10 połączonych obszarów (ekstentów), zamiast na 256 tysięcy bloków.[/quote]
Gigabajt = 1024MB
1024MB / 128 = 8
(nie 10!)
Czy może pozostałe 2 obszary, w sumie 256MB, są zajęte przez coś innego, co by przeczyło logice?
A co to za wredna mania spolszczania wszystkiego jak leci. Każdy wie co to jest „extent” a nigdy nie spotkałem się z tym że jest to „zakres”. Spotkałem się natomiast w tekstach z „mlaśnięciem myszką”.
Pingback: Co nowego w Ubuntu 9.10 Karmic Koala? :: Czytelnia Ubuntu
[quote comment=”38630″]A co to za wredna mania spolszczania wszystkiego jak leci. Każdy wie co to jest „extent” a nigdy nie spotkałem się z tym że jest to „zakres”. Spotkałem się natomiast w tekstach z „mlaśnięciem myszką”.[/quote]
No właśnie – po polsku jest „pstryknięcie” myszką (zapstryknąć, odpstryknąć,…). Ale to jest wredna mania – nie można po prostu pisać po angielsku i zapomnieć o języku Reja?
[quote comment=”35681″]Artykuł ciekawy. Kilka błędów by się znalazło, ale ja nie o tym.
Interesuje mnie problem fragmentacji. Strasznie mnie bawi, gdy czytam, że ext3 nie wymaga defragmentowania. Tu to samo, ale już że „będzie zaimplementowane później defragmentowanie w
[/quote]
A zauważyłeś, że w systemach extX dysk pracuje ciszej niż w fatXX czy ntfs? Nie wiem czy to jest spowodowane niższą fragmentacją, czy różnicą w zarządzaniu dyskami pomiędzy Linuksem a win, ale jak dla mnie słychać to wyraźnie.
Nawet jeżeli pod Linuksem zamontujesz partycję ntfs i zrobisz na niej choćby komendę find /mnt/win, to od razu słychać głośniejszą pracę dysku niż na partycji extX.
A ja spytam inaczej. Instaluje najświeższą wersje testową debiana na serwerze Dell, RAID 5 sprzętowo itd… wszystko idzie ładnie tylko nie na ext4. Instalacja przebiega bezproblemowo. Ładnie widoczny jeden dysk tak jak powinno być. Niestety po ponownym uruchomieniu kompa system ma problem z uruchomieniem i ładny napis kernel panic :-). Rozwiązaniem jest ustawienie partycji / na ext3. Jednak do końca mnie to nie zadowala. Może ma ktoś jakiś pomysł.
Bzyk, prześwietnie opisał jak dochodzi do defragmentacji dysku twardego ! I nie ważne jaki mamy system plików. Polecam utworzenia osobnej partycji ext4(20GB) dla torrenta i legalnie zaciągamy rożne i o rożnej wielkości dystrybucje linuxa i robimy z plikami tak jak to opisał Bzyk z kasowaniem plików. A potem sprawdzamy co się dzieje na partycji. Pozdrawiam :]