Wybieramy system plików 12


Od Redakcji: artykuł pochodzi z czerwcowego wydania Linux Magazine. Kompletną listę artykułów możecie znaleźć na stronach miesięcznika.

Wybór systemu plików zależy od konkretnych naszych potrzeb. By był świadomy, w tym miesiącu przyglądamy się z bliska różnicom pomiędzy kilkoma popularnymi systemami plików dostępnymi w Linuksie.

Możliwość dokonania wyboru to wspaniała sprawa, a współczesny Linux oferuje szeroką gamę systemów plików dla naszych cennych danych. W tym artykule omawiamy kilka zagadnień związanych z budową systemów plików i pokazujemy, jak podeszli do nich projektanci kilku wybranych popularnych systemów plików. Ujęcie z perspektywy projektanta systemu plików powinno dać nam pogląd, który z nich będzie najlepszy dla naszych zastosowań.

Problemy, problemy…

Na pierwszy rzut oka system plików wydaje się bardzo prostym tworem – wszystko, czego potrzebujemy, to upchnąć trochę danych do plików na dysku twardym i mieć do nich dostęp później, prawda?

Zgodnie z tym, system plików musi obsługiwać jedynie metadane plików i katalogów oraz ich wzajemnie relacje (zagnieżdżanie katalogów) i przechowywać ciągi bajtów jako zawartości plików. Być może system plików mógłby po prostu przechowywać metadane w tabeli zawierającej takie informacje jak nazwy i rozmiary plików, czasy modyfikacji itp. oraz wskaźniki do zawartości wszystkich plików?

Na tym etapie system plików wciąż wydaje się stosunkowo mało skomplikowany. Dołóżmy jednak do tego proste mechanizmy blokowania tabeli z metadanymi, by zapewnić jej spójność nawet w chwili, gdy kilka procesów korzysta z niej jednocześnie. Implementacja blokowania nie jest może jeszcze wielką przeszkodą, ale przecież dobrze byłoby mieć do dyspozycji także jakiś sposób indeksowania tabeli z metadanymi, co pozwoliłoby na szybki odczyt katalogów.

Ale zaraz… jeśli komputer straci zasilanie, lepiej byłoby, gdyby system plików wciąż nadawał się do użytku i zawierał wszystkie dane, gdy ponownie uruchomimy system. Wszystko powinno być w porządku także w przypadku, gdybyśmy podczas awarii zasilania zapisywali dane na dysk. Może nie dałoby się odzyskać wszystkiego, co było wówczas zapisywane, ale przynajmniej pozostałe dane powinny być spójne. Poza tym raczej nie chcielibyśmy czekać godzinami na zakończenie sprawdzania 2 TB nowego dysku przez fsck. Kilka sekund z pewnością wystarczy prostemu systemowi plików do stwierdzenia, że podczas awarii wykonywał pięćdziesiąt różnych czynności, i przywrócenia się do sensownego stanu.

Teraz sprawa zaczyna się komplikować. Jeśli system plików próbuje zaktualizować metadane, jak może określić, czy fragment tabeli z metadanymi jest prawidłowy, czy był jedynie częściowo zapisany w chwili utraty zasilania? A co z indeksem tej tabeli? Możliwa jest sytuacja, że tylko część indeksu została zapisana na dysk, a reszta oczekiwała w pamięci operacyjnej, gdy komputer utracił zasilanie. Naprawdę bardzo byśmy nie chcieli stracić metadanych, niezależnie od tego, co się stało. Indeks też musi być ciągle poprawny; w przeciwnym wypadku system plików nie może na nim polegać, więc równie dobrze mogłoby go nie być w ogóle. Nawet jeśli system plików potrafi stwierdzić, że system nie został poprawnie zamknięty, przebudowanie indeksu może trwać naprawdę długo i skończyć maratonem oczekiwania na zakończenie programu fsck, którego przecież wolelibyśmy uniknąć.

Wobec tego może system plików powinien tworzyć dziennik, w którym zapisywałby, jakie zmiany metadanych zostały zapisane w określonych momentach, oraz budować nową tabelę z metadanymi wraz z indeksem, uwzględniając dokonane zmiany. A po wykonaniu tego wszystkiego – szybko przełączać się na nowy zestaw danych. W ten sposób system zawsze miałby przynajmniej jedną prawidłową tabelę metadanych z prawidłowym indeksem i mógł przy pomocy dziennika zmian znaleźć się możliwie blisko stanu, w którym nastąpiła awaria zasilania. Taki system może działać, ale przebudowywanie indeksu przy każdej synchronizacji systemu plików ze zmianami może być bardzo czasochłonne.

Dlatego oprócz spójności danych od systemu plików oczekujemy także, że będzie tak szybki, jak to tylko możliwe. Jeśli rozpakowujemy 50 MB archiwum lub uruchamiamy rozproszoną kompilację – im prędzej wszystkie czynności są wykonywane, tym lepiej. Na szczęście nie musimy samodzielnie implementować własnego szybkiego i bezpiecznego systemu plików; Linux obsługuje kilka systemów plików, które radzą sobie z tymi problemami na różne sposoby.


Rysunek 1: Rozszerzony system plików (ang. Extended Filesystem, ext) przeszedł kilka ważnych etapów rozwoju.


Rysunek 2: Opracowany pierwotnie w Silicon Graphics system plików XFS z księgowaniem jest teraz rozwijany jako niezależny projekt.


Rysunek 3: System plików z b-drzewami (ang. B-tree Filesystem, Btrfs, wymawiane jak „butter fs”) wywołał ekscytację w świecie open source dzięki zaawansowanym możliwościom tworzenia migawek i rozpięcia na kilka urządzeń. Jak podaje wiki projektu, Btrfs jest dość nowy i wciąż mocno się rozwija.

Przechowywanie metadanych

Jak dotąd doszliśmy do wniosku, że dobrym pomysłem jest przechowywanie metadanych dotyczących plików i katalogów w abstrakcyjnej tabeli, która byłaby indeksowana w celu szybszego przeszukiwania. Gdy weźmiemy po uwagę, jak mogą być przechowywane katalogi, indeks staje się najważniejszym elementem odpowiedzialnym za wydajność systemu plików.

Każdy plik dostaje swój unikalny numer, i-węzeł (ang. i-node). Wówczas katalog jest listą i-węzłów oznaczających każdy z plików. By dowiedzieć się, kto jest właścicielem pliku, do jakiej należy grupy i jakie są atrybuty dostępu do pliku, system plików wykonuje kilkukrotne przeszukiwanie tabeli z metadanymi, wykorzystując numery i-węzłów jako wartości klucza. Wyszukiwanie metadanych pliku za pomocą numerów i-węzłów jest stosunkowo częstą operacją wykonywaną na przykład podczas sprawdzania uprawnień pliku, który próbujemy odczytać lub po prostu listujemy katalog.

Jeśli projekt systemu plików ogranicza liczbę dostępnych i-węzłów i rezerwuje ciągłą tabelę dla wszystkich tych węzłów w momencie tworzenia systemu plików, numer i-węzła może być użyty bezpośrednio do wyszukiwania wpisów w tabeli metadanych. Na przykład, jeśli na stronie pamięci mieści się 128 i-węzłów, to węzeł numer 600 będzie na piątej stronie. Wadą takiego systemu jest to, że tabela musi być ciągła i zaalokowana na początku. Użycie b-drzewa do przechowywania zarówno tabeli, jak i jej indeksu staje się zatem atrakcyjnym rozwiązaniem.

B-drzewo może być przydatne do implementacji indeksu, który pozwala przeglądać metadane pod kątem numeru i-węzła. Dla niewtajemniczonych: b-drzewo jest metodą indeksowania, pozwalającą szybko przeglądać kolekcję danych pod kątem wartości lub przedziału wartości klucza. Początki b-drzew datuje się na lata siedemdziesiąte dwudziestego wieku; b-drzewa przydają się w zastosowaniach takich jak systemy plików, gdyż pozwalają przeszukiwać dane przy stosunkowo niewielkiej liczbie odczytów z dysku twardego, a przy dodawaniu nowych danych b-drzewa pozostają zrównoważone (dla zwięzłości nie rozróżniamy w tym tekście b-drzew i b+drzew).

B-drzewa są stronicową strukturą danych, co oznacza, że dane są grupowane tak, by zajmować całe strony i odnosić się do innych stron. Wobec tego jeśli numer strony pamięci i klucz mają po 8 bajtów, początkowa strona o rozmiarze 4 KB może przechowywać odniesienia do dwustu pięćdziesięciu sześciu innych stron, z których każda może mieć odniesienia do dwustu pięćdziesięciu sześciu kolejnych itd. Jak widzimy, nie potrzeba wielu stron, by przechowywać tysiące, a nawet miliony wartości klucza. Ten spory zasięg każdej strony drzewa oznacza, że możemy znaleźć pojedynczą wartość klucza w b-drzewie z milionem wartości, przeglądając jedynie trzy strony. Pobranie każdej strony z dysku może wymagać operacji pozycjonowania głowic, która jest bardzo powolna, więc minimalizacja liczby stron do przeszukania jest w tej grze kluczowa. W miarę rozpowszechniania pamięci półprzewodnikowych ta reguła traci nieco na znaczeniu, aczkolwiek koszt tego typu pamięci w przeliczeniu na gigabajt jest obecnie tak spory, że staną się one naprawdę powszechnie dopiero za kilka lat.

Dolne elementy b-drzew przechowują dane odpowiadające określonej wartości klucza, które mogą wskazywać jakąś inną strukturę danych lub być właściwymi danymi, jeśli są wystarczająco małe. W przypadku systemów plików te dane to na przykład czas modyfikacji, właściciel, uprawnienia itp. – są na tyle niewielkie, że mogą być przechowywane bezpośrednio w b-drzewie. System XFS alokuje i przechowuje i-węzły w grupach po sześćdziesiąt cztery, a jego b-drzewo odnosi się do tych porcji.

Fakt, że b-drzewa są posortowane, może być wykorzystany przez system plików do zapewnienia wysokiej wydajności. Przykładowo, jeśli w katalogu tworzymy pięćdziesiąt plików, a system plików używa dla nich ciągu pięćdziesięciu kolejnych i-węzłów, pliki będą rozłożone w b-drzewie blisko siebie i mogą znaleźć się na tej samej stronie pamięci.

Całe to indeksowanie jest wspaniałe, ale wciąż nie rozwiązaliśmy problemu występującego przy odcięciu zasilania. Nie chcemy budować za każdym razem nowego indeksu b-drzewa i zawsze chcemy mieć pewność, że indeks jest prawidłowy.

Księgowanie i COW

Istnieją dwie główne strategie utrzymywania spójności metadanych systemu plików: używanie dziennika, przechowującego listę zmian, oraz używanie b-drzewa Copy-On-Write (COW). Jeśli system korzysta z dziennika, musi okresowo zmieniać swoje podstawowe struktury danych i zapisywać to w samym dzienniku. Podobny proces odbywa się w b-drzewach z COW, gdzie zmienia się korzeń drzewa.

Księgowanie (korzystanie z dziennika) metadanych jest zaimplementowane w systemach XFS, ext3 i ext4. B-drzewa COW są wykorzystywane przez Btrfs. Systemy z rodziny ext używają prealokowanej tabeli i-węzłów, XFS korzysta z b-drzewa i-węzłów, a Btrfs – z b-drzewa COW.

B-drzewa COW

Normalnie, jeśli aktualizujemy zawartość b-drzewa, strona pamięci zawierająca wartość klucza, której dotyczy zmiana, jest kopiowana do pamięci operacyjnej, tam zmieniana i potem z powrotem zapisywana na dysk twardy. Jeśli dodanie nowej wartości sprawia, że strona nie mieści się w swoje pierwotne miejsce, jest rozdzielana na dwie części, a nowa wartość dodawana do strony nadrzędnej (rodzica) strony, w której miała być zapisana. W b-drzewie COW wstawianie nowej wartości pozostawia stare drzewo nienaruszone i tworzy kopię strony, która ma być zmieniona. By wstawić potem tę stronę do drzewa, kopie wszystkich stron nadrzędnych także muszą zostać wykonane. Pamiętajmy, że każda strona ma niewiele (trzy do pięciu) stron nadrzędnych, bo ta struktura szybko się rozrasta; z tego powodu skopiowanie wszystkich przodków dowolnej strony nie jest kosztowną operacją. W tym momencie powstaje b-drzewo, które składa się z czterech, pięciu nowych stron, a wszystkie pozostałe strony dzieli ze starym drzewem. Wstawianie wartości tworzy kopię wszystkich węzłów nadrzędnych, więc za każdym razem drzewo ma nowy korzeń, dając nową „migawkę” (ang. snapshot) systemu plików po każdej operacji.

Z powodów wydajnościowych system plików wykorzystujący b-drzewa COW próbuje wykonywać możliwie wiele operacji na drzewie w pamięci RAM i tylko okresowo synchronizować skopiowane strony, tworząc nowy korzeń drzewa. Jeśli zmiany nie są od razu zapisywane, można wykonywać wiele operacji na kopii w pamięci operacyjnej, bez konieczności tworzenia kolejnej kopii tych samych danych, co wiąże się z ograniczeniem liczby odczytów z dysku.

Migawki dają możliwość zamontowania tylko do odczytu systemu plików w takim stanie, w jakim znajdował się w konkretnym momencie. Przykładowo możemy zobaczyć, w jakim stanie znajdował się nasz katalog domowy miesiąc temu. Migawka z możliwością zapisywania jest nazywana klonem i pozwala na przykład eksperymentować z różnymi zmianami w systemie przed faktycznym zdecydowaniem się na nie.

Chociaż wszystkie te kopie wydają się marnotrawić przestrzeń dyskową, pamiętajmy, że mówimy o kopiowaniu 4 KB stron pamięci, więc nawet jeśli skopiujemy miliony takich stron, wciąż dotyczy to przestrzeni dyskowej wartej kilka złotych. Gdy stare strony pamięci nie są już do niczego potrzebne, mogą być użyte ponownie, więc nie ma niebezpieczeństwa, że b-drzewo będzie rosnąć w nieskończoność i zajmie całą wolną przestrzeń twardego dysku.

Btrfs używa b-drzew COW do wszystkiego, możemy więc szybko zrobić migawkę całego systemu plików w dowolnej chwili.

Opróżnianie bufora

W dowolnej chwili system plików chciałby wiedzieć, czy konkretna porcja danych została już bezpiecznie zapisana na dysk. Przykładowo, czy dziennik lub wszystkie strony w nowym COW b-drzewie znajdują się już w całości fizycznie na dysku, a nie częściowo w wbudowanej w dysk 16 MB pamięci podręcznej.

Jedno polecenie magistrali SATA może być użyte do upewnienia się, że dane znajdują się na talerzu dysku, a nie jeszcze w buforze. Niestety, tym poleceniem jest polecenie opróżnienia całej pamięci podręcznej. Nie możemy powiedzieć: „Upewnij się, że dane z poleceń 12, 45 i 99 są już na dysku”, a przynajmniej nie na każdym sprzęcie. Musimy zakomunikować: „Zapisz na dysku wszystko, co masz w buforze”. Biorąc pod uwagę, że bufory dysków twardych mają zwykle rozmiar jedynie 16 lub 32 MB, że dane oczekujące na zapis niekoniecznie zajmują cały bufor oraz że można zapisywać dane na dysku z szybkością 100 MB/s, nie wydaje się to wielkim problemem. Ale jeśli uwzględnimy także to, że pamięć podręczna dysku wcale nie musi być jedynym miejscem oczekiwania danych na zapis (kontrolery dysków także mogą mieć swoje bufory), a dane mogą musieć zostać rozrzucone po całym dysku twardym, możemy być zmuszeni do odczekania chwili pod wydaniu polecenia opróżnienia pamięci podręcznej.

Opróżnianie bufora jest znane jako używanie barier dyskowych; systemy ext4, Btrfs i XFS domyślnie wykorzystują ten mechanizm. Chociaż operacje wiążące się z masową modyfikacją metadanych, takie jak tworzenie lub usuwanie dużej liczby plików, będą wolniejsze, system plików będzie dużo bardziej odporny na problemy spowodowane utratą zasilania. W tych systemach możemy wyłączyć bariery, jeśli chcemy, a ponadto musimy wiedzieć, że te bariery mogą nie działać z mechanizmem mapowania urządzeń (ang. device mapper) do kernela około 2.6.31, w zależności od tego, jakie łatki nałożyli twórcy dystrybucji, której używamy.

Wydaje się, że teraz powinniśmy być pewni, że potrzebujemy barier, jeśli działamy na maszynie bez bateryjnego podtrzymywania zasilania, a wciąż jednak troszczymy się o dane. Da się zauważyć, że włączenie mechanizmu barier może spowolnić operacje związane z metadanymi i synchronizację systemu plików nawet dziesięciokrotnie. To jest bezpośredni koszt wyboru między szybkością a odpornością na zakłócenia zasilania.

Zapisywanie zawartości plików

Istnieje wiele sposobów przechowywania na dysku bajtów składających się na plik. System plików, zapisując dane, musi wiedzieć, gdzie one lądują, by móc trafić do nich w przyszłości. Przy użyciu bloków system plików dzieli dysk na fragmenty o stałej wielkości, a każdy plik zawiera listę bloków, w których znajdują się części pliku.

W przypadku małych plików lista bloków może być zapisana razem z danymi i-węzła. W miarę jak plik robi się coraz większy, lista bloków pozwalająca odnaleźć wszystkie kawałki pliku robi się coraz większa i w efekcie plik staje się listą bloków odnoszących się do bloków zawierających wskaźniki właściwej zawartości pliku.

Oprócz przechowywania listy bloków inną wadą alokacji bloków o stałym rozmiarze jest fakt, że wielkie pliki składają się z wielu bloków, które niekoniecznie muszą znajdować się na dysku fizycznie blisko siebie. Oczywiście system plików może próbować zapisywać plik w blokach, które są możliwie niedużo oddalone.

Drugie podejście, oparte na ekstentach (ang. extent), skupia się na ciągłych porcjach bajtów. W idealnym świecie pojedynczy film o rozmiarze 10 GB mógłby być zapisany w jednym, ciągłym przedziale bajtów na dysku (czyli w jednym ekstencie). To wymagałoby niewielkiej ilości metadanych do zapisania położenia pliku z filmem oraz pozwoliło odczytać cały film przy użyciu jednej operacji pozycjonowania głowic.

Jak zapewne zauważyliśmy, użycie ekstentów i minimalna fragmentacja systemu plików powinny pozwolić na usunięcie dużego pliku znacznie szybciej niż przy alokacji bloków. Dave Chinner w swojej prezentacji podczas Ottawa Linux Symposium 2006 pokazał, że usunięcie jednego pliku 60 GB wymagało pięćdziesięciu sekund w systemie ext3, dwóch sekund w ext4 i czterech dziesiątych sekundy w XFS. Dwa ostatnie systemy używają ekstentów, więc mogą dać zauważalną poprawę, jeśli często tworzymy i usuwamy duże pliki (na przykład jeśli pracujemy z filmami).

Piętą achillesową takiego podejścia jest zjawisko fragmentacji plików. Patologicznym przypadkiem jest pobieranie obrazu dystrybucji Linuksa za pomocą sieci peer-to-peer. W miarę pobierania pojawiają się drobne fragmenty pliku znajdujące się pod różnymi offsetami i są zapisywane przez system plików. Efekt jest taki, że obraz dystrybucji składa się z setek bloków zawierających drobne kawałki.

By zapobiec fragmentacji plików, system plików może unikać zapisywania danych na dysku od razu; taka strategia nazywa się opóźnioną alokacją (ang. delayed allocation). Na przykład, program może chcieć zapisać dane, otwierając plik, następnie w pętli wielokrotnie zapisując porcje danych po 64 KB i w końcu zamykając plik. Jeśli system plików buforuje dane do chwili zamknięcia pliku przez program, może dokładnie określić, ile zajmą dane przed fizycznym zapisaniem ich na dysk. System plików z ekstentami może spróbować znaleźć pojedynczy fragment o wielkości najbliższej pożądanej i zapisać tam cały plik za jednym razem. W ten sposób nie tylko unika fragmentacji pliku, ale także wykonuje operację pozycjonowania głowic tylko raz. System plików oparty na blokach spróbuje znaleźć listę bloków znajdujących się blisko siebie na dysku i zapisać dane tak, by ograniczyć liczbę operacji przeszukiwania podczas odczytu pliku.

Istnieją funkcje typu fallocate (2), które pozwalają programowi z góry poinformować system plików o tym, jak duży będzie plik, ale nie wszystkie programy korzystają z takich funkcji, by wspomóc system plików.

Zjawisko fragmentacji plików występuje nawet przy korzystaniu z pomocy opóźnionej alokacji i fallocate. Na przykład jeśli system plików zapełni się w dziewięćdziesięciu procentach, do zapisania dużego pliku może być potrzebny więcej niż jeden ekstent, więc fragmentacja będzie musiała wystąpić. To jeden z powodów, dla których wiele systemów plików oferuje narzędzia do defragmentacji online.

W systemie plików XFS możemy użyć programu xfs_fsr, służącego do optymalizacji alokacji miejsca dla plików. Jedną z lepszych funkcji tego narzędzia jest możliwość określenia, jak długo ma działać. xfs_fsr sam pamięta, gdzie skończył, gdy zostaje uruchomiony ponownie. Dzięki temu możemy uruchamiać go na przykład na kilka godzin każdej nocy, a on sam będzie zaczynał od miejsca, gdzie się zatrzymał.

System plików ext4 dopiero zyskuje możliwość defragmentacji online. Program e4defrag pozwala zdefragmentować konkretny plik, chociaż (stan na początek 2010 roku) nie ma pakietu dla Fedory 11, 12 ani Rawhide.

Wybór systemu plików

Mając w głowie te wszystkie drzewa, COW b-drzewa i dzienniki, możemy zastanawiać się, który system będzie najlepszy. Najprostsza odpowiedź brzmi: to zależy. Prawdopodobnie najlepszym rozwiązaniem może być wypróbowanie więcej niż jednego i rozpoznanie zalet uwidaczniających się w konkretnych zastosowaniach.

Systemy z rodziny ext przechowują i-węzły w tablicy, XFS w – b-drzewie, a Btrfs używa b-drzew COW do wszystkiego. Ext3, ext4 i XFS do zachowania spójności w przypadku utraty zasilania wykorzystują dziennik. Systemy z rodziny ext lubią od czasu do czasu podczas uruchamiania systemu przeprowadzić krótkie sprawdzanie za pomocą fsck. Ext4, XFS i Btrfs domyślnie używają barier dyskowych, pozostawiając system ext3 odosobniony pod tym względem.

Wspólnym dla wszystkich systemów sposobem na przyzwoitą wydajność jest unikanie zbyt wielkiego zapełnienia dysku. System plików pełny w dziewięćdziesięciu, dziewięćdziesieciu pięciu procentach może być zmuszony do podejmowania decyzji, które spowodują rozproszenie zawartości i metadanych po całym dysku.

By zmniejszyć liczbę wystąpień „wyścigów blokowania”, wiele systemów plików jest dzielonych na mniejsze części. Na przykład system XFS dzieli się na wiele „grup alokacji”, które działają jak samodzielne, niewielkie systemy plików. To pozwala systemowi aktualizować dane współbieżnie, ponieważ zmiany w jednej grupie nie blokują pozostałych. Jedyne, na co powinniśmy uważać, to ryzyko podzielenia jednego dużego pliku pomiędzy wiele grup alokacji. W ten sposób narasta bowiem problem niewielkiej ilości wolnego miejsca.

Wiele systemów plików pozwala podczas formatowania wybrać rozmiar i-węzłów. Jeśli zamierzamy używać rozszerzonych atrybutów i oczekujesz wysokiej wydajności za cenę niewielkiego zmniejszenia wolnej przestrzeni, możemy ustawić rozmiar i-węzłów większy niż domyślny. Paradoksalnie, jeśli intensywnie korzystamy z rozszerzonych atrybutów, podwojenie rozmiaru i-węzłów może sprawić, że system plików będzie zużywał mniej przestrzeni na swoje metadane, i jednocześnie zwiększyć wydajność. Stanie się tak dlatego, że rozszerzone atrybuty i metadane będą mogły zmieścić się do jednego, większego węzła i system plików nie będzie musiał zajmować całego kolejnego 4 KB bloku tylko dlatego, że część informacji nie mieści się w jednym.

Przykładowo, w XFS lista ekstentów zawierająca mniej niż dziewiętnaście pozycji mieści się do i-węzła o domyślnym rozmiarze. Jeśli zaczniemy używać jednego lub więcej rozszerzonych atrybutów, będą one zapisywane tam, gdzie lista ekstentów. Jeśli atrybuty się nie zmieszczą, zostaną przeniesione do nowej strony w pamięci.

Po tym, jak dowiedzieliśmy się, jak Btrfs używa b-drzew z COW, łatwo zrozumieć całą ekscytację wokół tego systemu – systemu, który używa ekstentów i pozwala bardzo szybko tworzyć migawki i klony systemu plików. Główną wadą Btrfs jest to, że jest on relatywnie nowy. Wobec tego główną zaletę systemów z rodziny ext stanowi fakt, że są one dostępne od bardzo dawna. Jeśli bierzemy pod uwagę bezpieczeństwo swoich plików, możemy uznać to, że wielu użytkowników od bardzo dawna z powodzeniem używa ext3, za niemal gwarancję dostępności swoich danych.

Z drugiej strony system XFS znajduje się w jądrze od czasów serii 2.4, a dzięki ekstentom bardzo dobrze radzi sobie z dużymi plikami. Znaną słabością XFS jest powolność wielu operacji tworzenia i usuwania plików, dlatego jeśli zamierzamy często rozpakowywać archiwa z wieloma niewielkimi plikami (na przykład paczki z kodami źródłowymi), XFS może nie być najlepszym wyborem.

Podsumowując, jeśli będziemy przechowywali duże pliki i chcemy mieć możliwość ich defragmentacji, XFS to wspaniały wybór. Jeśli dynamiczna alokacja i-węzłów i ekstenty nas nie ekscytują, wybierzmy ext3 – rozwiązanie, które przetrwało próbę czasu. Ext4 to ext3 rozszerzony o ekstenty, za jakiś czas będzie miał możliwość defragmentacji online (e4defrag). Jeśli chcemy wykonywać szybkie migawki i klony systemu plików, Btrfs jest drogą, którą powinniśmy podążać. Możemy defragmentować system Btrfs za pomocą btrfsctl -d.

Jeśli od systemu oczekujemy szybkości i pewności, rozważmy przechowywanie dziennika systemu plików na dobrej pamięci SLC SSD lub zainwestujmy w bateryjne podtrzymywanie zasilania, co pozwoli wyłączyć bariery dyskowe.

Info

Autor: Ben Martin
Ben Martin pracuje nad systemami plików od ponad dziesięciu lat.
Obronił doktorat i obecnie oferuje usługi konsultingowe
związane z pakietem libferris,
systemami plików i programowaniem w C++/Qt.

Skomentuj empitt Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

12 komentarzy do “Wybieramy system plików

  • mlody969

    [quote post=”12623″]Zgodnie z tym, system plików musi obsługiwać jedynie metadane plików i katalogów oraz ich wzajemnie relacje (zagnieżdżanie katalogów) i przechowywać ciągi bajtów jako zawartości plików. Być może system plików mógłby po prostu przechowywać metadane w tabeli zawierającej takie informacje jak nazwy i rozmiary plików, czasy modyfikacji itp. oraz wskaźniki do zawartości wszystkich plików?
    Na tym etapie system plików wciąż wydaje się stosunkowo mało skomplikowany.[/quote]

    Weźmie taki laik pismo do ręki, przeczyta coś takiego i od razu mu się odechce linuxa jeżeli autor twierdzi że to mało skomplikowane a on nawet nie wie co to są metadane

  • empitt

    To wtedy sięgnie sobie po regułkę do słownika, a jeśli na to nie wpadnie, to już trudno się mówi. Jeśli czytelnik przeczyta sobie artykuł o systemie plików NTFS i będzie tam napisane, że trzeba ją co jakiś czas defragmentować, to nie sięgnie po Windowsa, ponieważ nie będzie wiedział co to znaczy defragmentacja. Właśnie z takim przypadkiem ostatnio się spotkałem i skończ ze swoimi nudnymi tekstami, ponieważ potrafisz tylko krytykować (praktycznie wszędzie gdzie się da). Ogólnie zawsze tak było i będzie, że Ci którzy dużo gadają, mało wiedzą.

  • garam

    empitt – dlaczego niby co jakiś czas TRZEBA defragmentować dyski NTFS? Sam jeszcze nigdy tego nie robiłem i nie widzę do tego najmniejszej potrzeby.

  • kub0l

    garam – ponieważ system plików ntfs ma tę wadę, że częste kopiowanie i usuwanie plików prowadzi do ich fragmentacji. W efekcie rośnie czas dostępu do danych a co za tym idzie spada wydajność systemu.

  • empitt

    @garam, bo skąd możesz wiedzieć jakie efekty przynosi defragmentacja NTFS skoro nigdy tego nie robiłeś. Ja miałem taką potrzebę, ponieważ po tym system żwawiej chodzi, nie wspominając już o defragmentacji rejestru.

  • kane

    świetny artykuł , no to w sumie jaki system plików będzie najlepszy do domowego użytku? bo z tego artykułu początkujący użytkownik tego się nie dowie,ja wiem że autor się starał i dobrze wszystko opisał mu linuksiarze to rozumiemy ale ktoś kto chce się przesiąść na pingwinka nic z tego nie zrozumie i się zniechęci

  • tomq

    Odkad tylko pamietam zawsze jechalem na ext3. Jak wspomnhano w tejscie jest on dla mnie gwarancja bezpieczenstwa. Ostatnio testowalem raiserfs i prawde powiedziawszy spisuje sie… Przyzwyczajenie jednak druga natura – ext3 rzadzi 🙂

  • Garry

    Ja tam polecam XFS lub JFS. Może nie do wszystkiego, ale na dyski, na których składuje się filmy i obrazy dysków. Systemy te mozna szyfrować, a spadku wydajności nie widać. No i przeżywaja brutalne wyłaczenie z palca.

  • hol

    Panowie, a który z w/w polecicie na:
    a) partycja z systemem,
    b) /home (od plików typu php/dużo – praca, przez doc’, mp3, aż po duże avi)
    c) partycje-przechowalnia duuużych plików

    Ad.b) zakładając że robię regularny backup

  • Outslider

    Panowie i co się kłócicie…:)

    Ja dla odmany w kwestii literackiej – artykuł od początku wkręca jak kryminał – powoli, spokojnie, zaczyna się rozkręcać, uszczegóławiać a potem się człowiek gubi w tym, kto zabił:D

    Ale technicznie bardzo ciekawy, wreszcie wiem, co to są i-nody!

  • sinus

    Ja od pewnego czasu używam systemu raiserFS. Nie jest najnowszy ale jak się ma sporo małych plików to jest na prawdę dobry.
    Dla partycji przeznaczonych głównie na duże pliki tak jak Garry polecem XFS lub JFS.

    Artykuł godny polecenia, zwłaszcza dla początkujących w tej materii – a to cenne.