Przy instalacji Linuksa zwykle do wyboru jest kilka systemów plików, takich jak ext4, ext3, ext2, reiserfs, xfs, niekiedy może reiser4. Mandriva Linux w wersjach 10 i starszych oferowała do wyboru wszystkie obsługiwane przez nią systemy plików, na oko było to około 60 pozycji – w tym wszelkie rodzaje FAT i NTFS – przy czym instalator nie umożliwiał instalacji na większości z nich (nieśmiertelny komunikat "(/) musi być na porządnym systemie plików"). W niniejszym artykule znajdziesz przegląd popularnych linuksowych systemów plików wraz z odwołaniami do tabel porównujących wydajność, subiektywną oceną przydatności w domowych warunkach i opisem narzędzi. Dla maniaków optymalizacji przygotowane zostały najciekawsze opcje tune2fs. Jeśli chcesz się dowiedzieć czegoś ciekawego na temat linuksowych systemów plików i nie tylko, zapraszam do czytania.
Szczegółowe informacje na temat wydajności, fragmentacji i specyfikacje techniczne popularnych systemów plików znajdują się w artykule Błażeja Piechny (informacje w tabeli z ograniczeniami są nieaktualne, po aktualne wartości proszę się udać na angielską Wikipedię lub strony domowe odpowiednich systemów plików).
Obecny w Linuksie od stycznia 1993, powstały na podstawie bardzo ograniczonego systemu plików Miniksa (początkowo ten system plików był używany na Linuksie); sam Linux był tworzony z użyciem tego systemu (nieśmiertelna [znowu] wiadomość Linusa anonsująca Linuksa). Nie będziemy się jednak o nim rozpisywać, ponieważ nie posiada on księgowania. Podobnie jak wszystkie wersje FAT.
Obecny w Linuksie od listopada 2001, niektórzy nazywają go "aktualizacją EXT2". Główna zmiana to wprowadzenie księgowania. Wydajność stoi na dobrym poziomie, co można zobaczyć w podlinkowanym wyżej zestawieniu. Wprowadza kilka trybów księgowania, które pozwalają dostosować szybkość versus bezpieczeństwo do własnych zastosowań. Domyślnie działa w trybie ordered. O księgowaniu i zmianie trybu księgowania można poczytać w artykułach podlinkowanych wyżej.
Jak widać EXT3 posiada solidne podstawy (EXT2 w czasach swojej świetności był chętnie używany w zastępstwie filesystemu Miniksa) i jest już wypróbowany w działaniu. Co więcej, w razie potrzeby można wymusić jego zamontowanie jako EXT2 i użycie bez księgowania. Jest to system plików zdecydowanie godny polecenia dla początkującego użytkownika, nadaje się też na serwer.
Jeśli chcesz utworzyć partycję w formacie EXT3, musisz użyć narzędzia mkfs.ext3. Może jednak najpierw zobaczmy gdzie jest jakaś wolna partycja używając cfdiska:
Czasem trzeba cfdiskowi podać odpowiednie urządzenie np. cfdisk /dev/hdb (zobacz artykuł o montowaniu).
W naszym przypadku będziemy "niszczyć" partycję sda5. A więc zakładamy system plików:
I sprawdzamy efekt:
Klaster - jednostka logiczna wypełnienia dysku przez dane. Jeden klaster może zawierać tylko jeden plik, nawet jeśli plik jest mniejszy niż rozmiar klastra. Dlatego im mniejszy rozmiar klastra, tym większa oszczędność miejsca, ale zwykle mniejsza wydajność.Z wyjścia mkfs.ext3 oprócz ciekawych informacji (np. rozmiar klastra: 4KiB, liczba zarezerwowanych bloków: 5%) dowiadujemy się o jeszcze jednym przydatnym narzędziu tune2fs. Zaraz się nim zajmiemy, ale najpierw zobacz, że wszystkie systemy plików tworzy się podobnie:
Większość poniższych opcji powinna działać także z EXT4.
Tune2fs pozwala nam - jak czytamy - zmienić domyślne ustawienia sprawdzania dysku. Mimo księgowania system plików ma zakodowane kompletne sprawdzenie poprawności danych co jakiś czas, czyli przy 27 odmontowaniu lub upływie pół roku flaga clean ustawiana jest na unclean i system uruchamia sprawdzanie przy włączaniu. Więcej o tym niżej. Domyślne ustawienia są raczej dobre do serwerów, bo w domu przecież komputer wyłączany i włączany jest najczęściej kilka razy w ciągu dnia, więc owe 27 montowań powodowałoby sprawdzanie dysku średnio co pół miesiąca.
Tune2fs zawiera też przełącznik -r, który w manualu opisany jest w taki sposób: Zmienia liczbę zarezerwowanych bloków na podanym urządzeniu. Na cóż one są zarezerwowane? Wyjaśnione jest to w manualu mkfs.ext3. Wolne miejsce na partycji pomaga utrzymać w ryzach fragmentację (jądro ma trochę wolnego miejsca na kompaktowanie plików) a w razie zużycia całego miejsca przez jakiegoś użytkownika zarezerwowany obszar zabezpiecza możliwość dalszego logowania zdarzeń przez sysloga.
Tune2fs nadaje również etykiety. Spróbujmy go użyć do zmiany ustawienia sprawdzania systemu plików na co 60 dni lub co 120 zamontowań w zależności do tego co wystąpi pierwsze. Nadajmy partycji jakąś etykietkę. Zmieńmy wreszcie obszar zarezerwowany na 0 i porównajmy dostępne dla użytkownika miejsce na dysku:
Teraz
Przedtem:
Zaoszczędziliśmy prawie 315MB.
EXT 4 już zoptymalizowane:
Dodatkowe 136 bajtów (ten test przeprowadziłem na innej partycji, innym systemie i innym dysku, być może faktycznie różnicy nie ma).
Dla celów porównawczych ta sama partycja z reiserfs:
Jeszcze 209 MB dodatkowego miejsca.
Skoro jesteśmy tak daleko, to jeszcze XFS:
+ 18MB na korzyść XFS.
Mamy też nową etykietkę:
Przyjrzyjmy się takiemu wpisowi w /etc/fstab:
Zacznijmy może od tego, czemu system plików opisany został jako ext4. Na partycji /home znajduje się system plików ext3, jednakże od jądra 2.6.27 (wersję można sprawdzić poleceniem uname -a) możliwe jest wykorzystanie modułu ext4 od obsługi ext3. Dzięki temu przyspieszysz alokację większych plików oraz zmniejszysz fragmentację dzięki opóźnionej alokacji (działa lepiej w połączeniu z większym commit interval). Uzycie modułu ext4 na systemie plików ext3 nie spowoduje zmiany formatu na ext4, takiej partycji można później swobodnie używać na systemie nieobsługującym ext4.
Opcja noatime spowoduje, że fakt dostępu do każdego pliku nie będzie zapisywany w systemie plików. Powinno to spowodować redukcję liczby zapisów na dysk i przyspieszenie otwierania katalogów z wieloma elementami.
Commit interval wyrażany w sekundach to czas, po jakim dane z buforów dyskowych zostaną zapisane fizycznie na dysk. Domyślnie jest to 5 sekund. Zwiększenie tego czasu w znaczny sposób podnosi wydajność, jednak przy awarii zasilania spowoduje utratę danych zbuforowanych między kolejnymi cyklami zapisu.
Manuale - większość przedstawionych tutaj poleceń posiada przystępną pomoc po polsku dostępną z konsoli po wpisaniu man program lub w pasku adresu Konquerora man:program.Do sprawdzania poprawności systemu plików służy program fsck, fsck.ext3 lub e2fsck. Właściwie wychodzi na jedno czego użyjemy, i tak uruchomiony zostanie w końcu e2fsck. Czemu tak śmiesznie? Zacznijmy od końca. E2fsck to po prostu właściwa nazwa programu do sprawdzania poprawności ext2, ext3 i ext4. Fsck.ext3 to ukłon w stronę użytkownika, który musi znać tylko polecenie fsck:
Fsck jest używany w skryptach startowych, gdzie rozpoznaje typ systemu plików i uruchamia odpowiednie narzędzie (o tych skryptach będzie jeszcze niżej). Przed użyciem e2fsck trzeba koniecznie odmontować partycję. Aby przekonać się o tym samym efekcie końcowym, spróbujmy sprawdzić dysk na wymienione 3 sposoby:
Tego nie widać na stronie, ale sprawdzenie odbyło się naprawdę błyskawicznie. Bo tak właściwie e2fsck sprawdził tylko, że system plików oznaczony jest flagą clean i odmówił w związku z tym dalszego sprawdzania. Wyżej w akapicie o konfiguracji tune2fs było powiedziane o tym, że ta flaga zostaje ustalona na unclean po 27 odmontowaniu (my ustaliliśmy tę wartość na 120) i przy uruchomieniu systemu następuje wymuszenie sprawdzenia konsystencji mimo księgowania. Zobaczmy jak to działa:
Po tym sprawdzeniu flaga unclean zostanie znowu zmieniona na clean i partycja przy starcie nie będzie sprawdzana. Sprawdzenie można także wymusić na żądanie (tym razem chcemy widzieć także więcej informacji - opcja -v.
Stworzony specjalnie dla Linuksa przez firmę Namesys w 2001 roku używa mechanizmów podobnych do bazy danych, co powoduje szybszy dostęp do dużej ilości małych plików. Księgowanie podobne jest w końcowym efekcie do ext3 ordered. Dodatkowo pozwala na użycie pojedynczego klastra do przechowywania kilku plików, co efektywnie zwiększa ilość miejsca dostępnego dla użytkownika i zmniejsza wewnętrzną fragmentację. Wyłączenie tej opcji i zwiększenie szybkości uzyskujemy opcją notail.
Wewnętrzna fragmentacja - zarezerwowanie przestrzeni bez intencji jej użycia. Oprócz wspomnianej sytuacji z klastrami podobnie ma się z programami, które rezerwują dla zmiennych zwykle więcej pamięci RAM, niż to jest im faktycznie potrzebne. Powodem tego zjawiska jest chęć uproszczenia budowy rozwiązań informatycznych.Dzięki wspomnianej funkcji efektywnie zmniejsza się również wartość fragmentacji danych (czyli tej, którą usuwają defragmentatory). Reiserfs to najmniej fragmentujący się popularny system plików dla Linuksa wśród uznanych za stabilne.
W porównaniu podlinkowanym wyżej można sprawdzić dokładnie gdzie reiserfs jest lepszy, a gdzie gorszy od ext3. Jak widać teoretyczne założenia nie zawsze idą w parze z praktyką. Dodatkowo reiserfs zużywa więcej czasu procesora do działania. Warto też wspomnieć, że główny developer, założyciel Namesys, Hans Reiser siedzi w więzieniu za zabójstwo żony, więc o ile reiserfs znajduje się już w jądrze Linuksa, o tyle ma na pewno mniejsze wsparcie niż gdyby jego autor był na wolności.
Reiserfs jest również mniej odporny na uszkodzenia struktury. W razie niepowodzenia jej naprawy z kroniki zwykle przebudowane musi zostać całe drzewo systemu plików co nie zawsze się udaje i może być skutecznie zakłócone istniejącym na przebudowywanej partycji obrazem jakiejś partycji z reiserfs.
Nie twierdzę, że reiserfs jest zły, ale wydaje mi się, że ext3 nie będzie gorszy w większości zastosowań, a jego prosta budowa i większa dojrzałość zapewniają lepsze bezpieczeństwo danych. Z tego powodu i ponieważ ogólny wzór obsługi systemu plików został podany w dziale o EXT3, ograniczę się tu jednynie do napisania, że utworzyć system plików reiserfs można za pomocą polecenia mkfs.reiserfs, sprawdzić przez reiserfsck, a skonfigurować przy użyciu reiserfstune. Opcję notail włącza się przy montowaniu.
Nie będziemy zajmować się też reiserem4, który nie został włączony do jądra Linuksa, choć firma Namesys uznała go za stabilny. Jego fani zapewne znajdą sposób na jego włączenie w jądro i przetestowanie. Nikt rozsądny jednak nie używa go na maszynie produkcyjnej.
Wyprodukowany w 1994 roku przez firmę Silicon Graphics dla IRIX-a. Zwycięża szybkością w prawie każdym zestawieniu, jednak jego księgowanie w przypadku awarii zasilania nie zapewnia bezpieczeństwa danych, a jedynie sprawność struktury systemu plików. Zawiera wiele ciekawych mechanizmów takich jak określenie minimalnego transferu dla konkretnego pliku, rozszerzone uprawnienia i inne nieprzydatne w domu funkcje. Do rozważenia w przypadku mało istotnych rzadko zapisywanych danych lub jeśli jest się szczęśliwym posiadaczem UPS-a, czy laptopa.
Przełącznik -f posłużył do wymuszenia nadpisania istniejącego na dysku ext3.
XFS w odróżnieniu od innych systemów plików sprawdzany jest przy montowaniu, tak więc polecenie fsck.xfs nic nie robi. Aby sprawdzić i naprawić XFS-a używane są polecenia xfs_check i xfs_repair. Na prawidłowym systemie plików, który był wcześniej zamontowany (zobacz dolny fragment działu Partycja root (/) na poprzedniej stronie) xfs_check nie powinien niczego wyświetlić. W przeciwnym razie system plików może być naprawiony od razu przy użyciu xfs_repair lub bezpieczniej za pomocą xfsdump i mkfs.xfs: najpierw zrzucamy obraz partycji do pliku, tworzymy na jej miejsce nowy system plików, a później używamy xfsrestore, aby przywrócić dane na nowy system plików. Xfsdump nie zadziała jednak na uszkodzonym systemie plików. Jeśli system plików jest montowalny, xfsdump może zostać użyty do odzyskania cennych plików przed zastosowaniem xfs_repair. W przypadku, gdy partycji nie można zamontować, xfs_repair to jedyne rozwiązanie.
XFS posiada wiele opcji konfiguracyjnych i funkcji, jednak inaczej niż w przypadku ext3, zwykły użytkownik nie ma raczej powodu do ich ruszania. Dla porządku podaję jednak dostępne możliwości:
Na poprzedniej stronie wspominałem o namiastce defragmentatora, jaką jest xfs_fsr. Zobaczmy jak to działa:
Co się stało? xfs_fsr pobrał z /etc/mtab listę systemów plików, wybrał najbardziej pofragmentowane pliki i rozpoczął ich kopiowanie (w jednym kawałku) do tymczasowej lokalizacji. Po skopiowaniu zmienił metadane tak, aby wskazywały na nowy plik. Gotowe. Program wyłączy się po dwóch godzinach. Extents wskazuje na liczbę fragmentów (przed i po). Wydawać by się mogło, że w tym konkretnym przykładzie plik w 69 kawałkach powinien być defragmentowany przed wszystkimi innymi. Nie stało się tak przypuszczalnie dlatego, że nie było odpowiednio dużej ciągłej wolnej przestrzeni dla niego, stąd defragmentacja mniejszych i mniej pofragmentowanych plików na początku.
Naturalnie takie defragmentowanie na ślepo jest dobre może na serwery, ale my chcemy wybrać system plików, czas działania i zobaczyć fragmentację plików. Sprawdźmy więc najpierw ogólny poziom fragmentacji:
Dużo. Ogromnie dużo. A ponoć linuksowe filesystemy miały się nie fragmentować! Sprawdźmy jednak zajęte miejsce:
Też dużo. Poniżej framgentacja kilku wybranych plików:
Jak widać 97% miejsca jest zajętego, czyli trochę za dużo. Plik kasia_backup.bin2.bz2 zajmuje 1,7GB i jest w miarę nowy, choć przy jego tworzeniu jeszcze było trochę miejsca – 8 kawałków. mbr.bin to tylko 512 bajtów, a ~1GB film Nad Niemnem (do celów edukacyjnych wolno ;) ) leży już tu od niepamiętnych czasów – 3 kawałki. Inny ~1GB plik wrzucony niedawno a niepokazany na listingu podzielił się na aż 21 fragmentów. Pozostaje pytanie jakie to ma znaczenie przy tak wielkich plikach, jeśli te mniejsze przechowywane są w 1 kawałku. Dla mnie żadnego, naprawdę. Pliki kopiują się maksymalnymi szybkościami. Spróbujmy jednak uprzeć się i zdefragmentujemy pierwszy plik:
No tak, za mało ciągłego miejsca. Ale przynajmniej wiesz jak to zrobić :] Podobnie można za argument podać konkretną partycję. Przy podaniu konkretnego pliku lub urządzenia można określić czas -t działania w sekundach. xfs_fsr przeprowadzi w tym czasie kilka przebiegów, defragmentując za każdym razem 10% najbardziej pofragmentowanych plików.
System plików powstały na bazie EXT3, kompatybilny z nim (partycję ext3 można zamontować jako ext4 i na odwrót, pod warunkiem że ext4 nie używa ekstentów, czyli upychania kilku plików na jeden klaster jak w reiserfs). 25 grudnia 2008 został wydany jako stabilny wraz z jądrem 2.6.28, mimo wszystko zalecam ostrożność w jego używaniu. Na wielu niezależnych stronach przewijają się opinie, że powinniśmy dać mu jeszcze rok na przetestowanie w bojowych warunkach, zanim ostatecznie się na niego zdecydujemy. Większość popularnych dystrybucji stosuje EXT4 domyślnie. W chwili pisania tego tekstu nie było stabilnej wersji GRUB-a, który potrafiłby uruchomić system, gdy na / znajduje się ext4, stąd używanie patchowanej wersji GRUB-a lub niestabilnego GRUB-a 2.
Z ciekawych funkcji ext4 można wymienić możliwość defragmentacji bez odmontowywania, szybsze sprawdzanie poprawności, jeszcze lepsze bezpieczeństwo (przynajmniej w teorii dzięki sumom kontrolnym kroniki) i większą szybkość (połączenie writeback z sumami kontrolnymi). Defragmentacja oraz ostatnia opisana funkcja ciągle nie są zaimplementowane [stan na 29.11.09]. Artykuł o tym jak przejść na ext4 z ext3, oficjalne wiki na temat ext4 i wreszcie porównanie wydajnościowe z innymi systemami plików (benchmark). Trzeba podkreślić, że migracja EXT3 > EXT4 jest możliwa i nie powoduje utraty wydajności w porównaniu z "czystym" ext4, natomiast kosztuje utratę kompatybilności z zewnętrznymi narzędziami obsługującymi ext3 (na Windows na przykład). Powrót EXT 4 > EXT 3 nie jest możliwy konwencjalnymi sposobami.
Formatowanie przeprowadzamy analogicznie jak w innych systemach plików:
Analogicznie do ext3, patrz wyżej
Do chwili udostępnienia oficjalnego narzędzia do defragmentacji możemy posłużyć się programem defrag, patrz poprzednia strona
Anaglogicznie do ext3, patrz wyżej
Anaglogicznie do ext3, patrz wyżej
Anaglogicznie do ext3, patrz wyżej
© Marcin Kocur (marcin2006 AT gmail COM), licencja: Creative Commons 3.0 Uznanie autorstwa-Użycie niekomercyjne-Na tych samych warunkach