Czas na btrfs

Wszystko na temat systemu plików następnej generacji

Btrfs, określany jako system plików następnej generacji dla Linuksa, ma wiele właściwości, których nie znajdziemy w pozostałych linuksowych systemach plików. W dodatku system ten można już uznać za nadający się do praktycznego użytkowania.

Jeśli wierzyć licznym artykułom opublikowanym w ostatnich miesiącach, to btrfs należy uznać za przyszłościowy system plików dla Linuksa. Również sami twórcy systemów plików są tego zdania: btrfs ma stać się systemem plików następnej generacji dla Linuksa. Ogólny wydźwięk opinii miłośników btrfs, a niekoniecznie samych programistów, sprowadza się do następującego twierdzenia: btrfs to ZFS dla Linuksa (tak twierdzą chociażby redaktorzy "Linux Magazine"). Można się z tym nie zgadzać (ZFS jest już stosowany w systemach produkcyjnych, a btrfs ma wciąż status produktu eksperymentalnego), jednak faktem jest, że obydwa systemy plików mają wiele wspólnego. Ze zintegrowanymi mechanizmami zarządzania woluminami, sum kontrolnych w celu ochrony danych, kopiowania podczas zapisu (copy on write) i zrzutów (snapshots) btrfs zawiera zbiór funkcji, których nie znajdziemy w żadnym nadającym się obecnie do zastosowań produkcyjnych systemie plików dla Linuksa.

Nazwa btrfs, która po angielsku jest wymawiana zarówno jako ButterFS, jak i BetterFS, jest właściwie skrótem od B-Tree FS, ponieważ system ten przechowuje dane i metadane w strukturach drzewiastych. Począwszy od wersji 2.6.29 jądra Linux, btrfs – rozwijany głównie przez zatrudnionego w koncernie Oracle Chrisa Masona – jest integralną częścią kernela. Nie oznacza to jednak, że jest stabilny, ani też, że nadaje się do zastosowań w środowiskach produkcyjnych: jak można przeczytać na podstronie poświęconej btrfs w serwisie kernel.org, na razie nie ustalono nawet ostatecznie formatu struktur danych na dysku.

Jednak w jednym z wywiadów, którego Mason udzielił Amandzie McPherson z Linux Foundation, ujawnił on dalsze plany związane z btrfs: w dopiero co opublikowanej pierwszej wersji przedwstępnej kernela 2.6.31 udało się zlikwidować większość problemów związanych z wydajnością. Tym samym ukazane niedawno kontrowersyjne porównania wydajności (np. autorstwa serwisu Phoronix) między btrfs a innymi linuksowymi systemami plików wydaje się raczej niemiarodajne. W kernelu 2.6.32 btrfs ma być zaimplementowany w stanie umożliwiającym jego pierwsze poważne testowanie. Czas więc rzucić okiem na linuksowy system plików następnej generacji.

Zaprojektowany z myślą o przyszłości

Jako system 64-bitowy btrfs adresuje do 16 eksabajtów (16 384 petabajtów) danych – zarówno w odniesieniu do maksymalnego woluminu, jak i maksymalnej wielkości pliku. Jest to znacznie więcej, niż może zaproponować ext4 (1024 petabajty/16 terabajtów), a tyle samo, ile sunowski system ZFS. W tym względzie btrfs dysponuje bogatą rezerwą na następne lata. Dla zobrazowania tego zagadnienia: na potrzeby Wielkiego Zderzacza Hadronów w centrum badawczym CERN, który jest obecnie z pewnością największym na świecie generatorem danych, przygotowano około 20 petabajtów pojemności dyskowej – jest ona rozproszona w gridzie rozlokowanym na serwerach w ponad jedenastu centrach obliczeniowych w Europie, Ameryce Północnej i Azji.

Również inne koncepcyjne właściwości btrfs przywodzą na myśl system ZFS:

btrfs zapisuje metadane i bloki danych w dwóch strukturach drzewiastych – jednej dla nazw katalogów i plików, a drugiej dla bloków danych;

bloki danych są obsługiwane za pośrednictwem extentów zamiast list bloków, co zwiększa wydajność, zwłaszcza w przypadku dużych plików (szczegóły na temat mechanizmu extentów znajdują się w artykule "Linuksowy system plików ext4"). Małe pliki mogą być zapisywane bezpośrednio w liściach drzewa; pozwala to uniknąć niepotrzebnego wykorzystywania extentów do obsługi niewielkich rozmiarowo plików;

btrfs wykorzystuje koncepcję kopiowania przy zapisie (copy on write): zmodyfikowane pliki zapisywane są w nowych blokach danych, dzięki czemu nie traci się starych informacji. Dopiero po zapisie danych następuje aktualizacja drzewa – do tego momentu wpis pliku wskazuje na stare bloki. Mechanizm copy on write wyłącza się za pomocą opcji montowania nodatacow;

system plików btrfs pracuje w trybie data=ordered, który zapewnia, że zmiany w metadanych są dokonywane dopiero po zapisie na dysk przynależnych danych właściwych. Dzięki temu po awarii systemu lub odcięciu źródła zasilania w teoretycznie zapisanych już informacjach nie pojawiają się stare wartości, które wcześniej były zapisane w blokach przewidzianych dla danego pliku;

mechanizm copy on write pozwala na tworzenie zapisywalnych zrzutów zawartości dysku (snapshots);

w systemie plików są wbudowane funkcje RAID (obecnie jedynie dla RAID-0, RAID-1 i RAID-10). Możliwe jest podłączanie i odłączanie urządzeń w czasie działania systemu. Brakuje jeszcze obsługi RAID-5 i RAID-6 z jednym, względnie dwoma nadmiarowymi dyskami;

możliwe jest jednoczesne utrzymywanie wielu podwoluminów (subvolumes) w ramach jednego woluminu (partycji) – btrfs zawiera obsługę mechanizmu zarządzania woluminami LVM (Logical Volume Manager);

sumy kontrolne zabezpieczają bloki danych i metadanych oraz pozwalają na rozpoznawanie błędnych danych; w przypadku obecności skonfigurowanej macierzy RAID-1 lub RAID-10 da się też korygować błędne dane za pomocą danych z napędu lustrzanego. Zachowanie to można wyłączyć za pomocą opcji montowania nodatasum.

Oprócz tego btrfs dysponuje rozmaitymi innymi funkcjami, których obecności oczekuje się w nowoczesnych systemach plików:

I-węzły są zakładane dynamicznie, w razie potrzeby; nie istnieją statyczne tabele I-węzłów, które byłyby zapisywane już w czasie tworzenia systemu plików;