SYSTEM PLIKÓW XFS

System plików XFS

XFS jest system, który został zaprojektowany od pierwszego dnia dla systemów komputerowych z dużą liczbą procesorów i dużych dysków. Skupia się na obsłudze dużych plików i dobrej wydajności we/wy strumieniowej. Ma też kilka interesujących funkcji administracyjnych, które nie są obsługiwane przez inne systemy plików Linux.
W tym artykule przedstawiono podstawowe informacje o tym, dlaczego został utworzony XFS i jak różni się od znanych systemów plików Linux. Może się okazać, że XFS jest tym, czego potrzebuje twój projekt, zamiast robić to z domyślnym systemem plików Linux.

Przez lata standardowym system plików Linuksa był ext2, prosta pochodna Berkeley FFS. Pod koniec lat dziewięćdziesiątych kilku konkurentów postanowiło nagle, aby wypełnić lukę w systemie plików zapewniającym szybkie odzyskiwanie danych po awarii integralności transakcji w metadanych. Wyraźnym zwycięzcą w głównym nurcie był system Linux oparty na ext3, który dodawał dzienniki do wersji ext2 bez wielu dodatkowych zmian. XFS był mniej znany wielu przeciętnym użytkownikom systemu Linux, ale zawsze był najwyższym osiągnięciem. Sam XFS nie pochodzi z Linuksa, ale po raz pierwszy został wydany na IRIX, wariant UNIX dla stacji roboczych SGI i serwerów, w grudniu 1994 roku, prawie 15 lat temu. Począwszy od 1999 r. XFS został przeniesiony do Linuksa w ramach push SGI do korzystania z Linuksa i procesorów Itanium firmy Intel dla swoich zaawansowanych systemów super-komputerowych. Zaprojektowany od samego początku dla dużych systemów wieloprocesorowych i macierzy dyskowych, a nie dla małych, jedno-rdzeniowych stacji roboczych dla klientów indywidualnych, od dawna znajdował się nad głównym rynkiem Linuksa. Dzisiaj nawet niskonakładowe stacje robocze z małą liczbą rdzeni i dysków CPU zbliżają się do granic ext3 (patrz tabela 1). Chociaż istnieje jeszcze jedna adaptacja koncepcji FFS o nazwie ext4 w trakcie opracowywania w celu złagodzenia tych granic w pewnym stopniu, wydaje się, że podstawowy projekt FFS jest bliski końca. Aby rozwiązać te granice, ext3 rozwija się w ext4 poprzez włączenie funkcji zapoczątkowanych przez XFS, takich jak opóźnione przydziały i rozszerzenia. Nawet przy tych ulepszeniach, biorąc podstawowy projekt FFS, trudno jest dopasować limity skalowalności XFS, które zostały zaprojektowane dla dużych systemów pamięci masowej od początku. W ciągu kilku lat btrfs, który jest nowym system plików zainicjowanym przez firmę Oracle, dojdzie do takiego stanu rozwoju, że stanie się nowym standardowym systemem plików. Jako nowy projekt, który obejmuje zaawansowane funkcje zarządzania i samouzdrawiania, btrfs będzie konkurował z XFS na dolnym końcu rynku XFS, ale musimy zobaczyć, jak dobrze robi na najwyższym poziomie.
Obecnie XFS jest używany przez wiele znanych instytucji, z CERN i Fermilab zarządzającymi petabajtami pamięci masowej do eksperymentów naukowych przy użyciu XFS i kernel.org tworzącym kod źródłowy dla jądra Linuksa i wielu innych projektów z systemów plików XFS.

Podział i zarządzanie przestrzenią

Każdy system plików XFS jest podzielony na regiony o nazwie grupy alokacji (AGs). Grupy alokacji są nieco podobne do grup blokowych w ext3, ale AGs są zwykle znacznie większe niż grupy blokowe i są wykorzystywane do skalowalności i równoległości, a nie do lokalizacji dysku. Grupy alokacji zazwyczaj mają rozmiar od 0,5 do 4 gigabajtów i zachowują wielkość struktur danych XFS w zakresie, w którym mogą działać skutecznie i równolegle. Historyczne systemy plików UNIX, w tym ext3, wykorzystują liniowe mapy bitowe do śledzenia wolnego miejsca, co jest nieefektywne, zwłaszcza w przypadku większych, ciągłych przydziałów. XFS zamiast tego używa pary drzew B + w każdej grupie alokacji. Każdy wpis w węzłach drzewa B + składa się z pary startowej i pary długości opisującej obszar wolnego obszaru. Pierwsze drzewo B + jest indeksowane przez blok początkowy wolnego obszaru, a drugie jest indeksowane przez długość wolnego obszaru. Ta podwójna indeksacja pozwala alokatorowi rozważyć dwa cele dotyczące nowego umieszczania danych: lokalizację dla istniejącego pliku i najlepsze dopasowanie do wolnego miejsca. W podobnym stopniu koncepcja jest używana do śledzenia bloków dysku przypisanych do każdego pliku. Oprócz bloku startowego na dysku i długości ciągłego zakresu opis deskryptora zakresu zawiera również dwa dodatkowe pola. Pierwszy to przesunięcie logiczne w pliku, co pozwala na sprawne rozsianego wsparcia plików, pomijając zakresy, które nie mają bloków przypisanych do nich. Druga to prosta jedno-bitowa flaga, która w znacznym stopniu jest niezapisywana, co zostanie wyjaśnione w dalszej części tego artykułu. W większości plików prosta liniowa deskryptora zakresu jest osadzona w inode, unikając dodatkowych bloków metadanych i zarządzania przepełnieniami. W przypadku bardzo dużych plików lub plików zawierających wiele dziur liczba rozszerzeń może być zbyt duża, aby można je było dopasować bezpośrednio do inode-a. W tym przypadku zakresy są śledzone przez inne drzewo B + z jego korzeniami w inode. To drzewo jest indeksowane przez przesunięcie w pliku, co pozwala na szybkie znalezienie deskryptora zakresu dla danego przesunięcia pliku, bez liniowego przeszukiwania. Rysunek 1, pokazuje czas potrzebny do usunięcia dużego pliku, takiego jak obraz wideo HD lub obraz maszyny wirtualnej, obrazuje przy tym jak można zredukować koszty zarządzania za pomocą rozszerzeń.

Inodes i Rozszerzone Atrybuty

Węzeł XFS składa się z trzech części: rdzenia inode, widelca danych i widelca atrybutu opcjonalnego. Rdzeń inode zawiera tradycyjne metadane UNIX, takie jak właściciel i grupa, liczba bloków, znaczniki czasu i kilka dodatków specyficznych dla XFS, takich jak identyfikator projektu. Widelec danych zawiera wcześniej wspomniane deskryptory zakresu lub korzenia mapy zakresu. Opcjonalny widelec atrybutów zawiera tak zwane atrybuty rozszerzone. Koncepcja rozszerzonych atrybutów nie jest częścią interfejsu systemu plików Posix, ale jest obsługiwana przez wszystkie nowoczesne systemy operacyjne i systemy plików z nieco odmienną semantyką. W Linuksie rozszerzone atrybuty to proste pary nazwy / wartości przypisane do pliku, który może być wymieniony i czytany lub zapisywany jeden atrybut naraz. Rozszerzone atrybuty są wewnętrznie używane przez Linuksa do implementowania list kontroli dostępu (ACL) i etykiet dla SELinuksu, ale mogą być także wykorzystane do przechowywania dowolnych metadanych użytkowników [3]. Widelec rozwiązywania zadań w XFS może albo przechowywać atrybuty rozszerzone bezpośrednio w indzie, jeśli przestrzeń wymagana dla atrybutów jest wystarczająco mała lub użyj tego samego deskryptora deskryptorów zakresu, opisanego dla danych plików powyżej, aby wskazać dodatkowe bloki dysku. Pozwala to XFS na obsługę rozszerzonych rozmiarów atrybutów do 64 kilobajtów, podczas gdy większość innych systemów plików Linux jest ograniczona do rozmiaru pojedynczego bloku dysku. Wielkość rdzenia inodowego jest stały, a widły atrybutów danych i atrybutów dzielą pozostałą przestrzeń w inozie, która jest określona przez rozmiar inode wybrany w czasie tworzenia systemu plików w zakresie od 256 do 2048 bajtów. W systemach plików, które w znacznym stopniu wykorzystują ACL (np. W przypadku plików akcji systemu Windows wyeksportowanych przez Sambę) lub w systemach plików wykorzystujących obszerne atrybuty, wybranie większego rozmiaru inode może zapewnić poprawę wydajności, ponieważ te dodatkowe dane mogą być przechowywane w nie wymaga odczytu dodatkowych bloków danych. Inodes w XFS są dynamicznie przydzielane, co oznacza, że ​​w przeciwieństwie do wielu innych systemów plików Linux ich lokalizacja i numer nie są określone w czasie mkfs. Oznacza to, że nie ma potrzeby przewidywania oczekiwanej liczby wstawek podczas tworzenia systemu plików, z możliwością niedopełnienia lub nadmiernego nadzoru. Ponieważ każdy blok w systemie plików może ewentualnie zawierać węzły, potrzebna jest dodatkowa struktura danych w celu śledzenia lokalizacji i alokacji inode. W tym celu każda grupa alokacji zawiera inne drzewo B +, śledzące przydzielone do niej atlowe węzły. Z tego powodu program XFS stosuje rzadki schemat liczby indyków, w których numerach inode koduje lokalizację inode na dysku. Chociaż ma to zalety przy wyszukiwaniu węzłów, oznacza to również, że w przypadku dużych systemów plików numery indytów mogą łatwo przekroczyć zakres kodowany przez 32-bitową liczbę całkowitą. Mimo że Linuks obsługuje 64-bitowe liczby inodowe od ponad 10 lat, wiele aplikacji przestrzeni użytkownika w systemach 32-bitowych wciąż nie może pomieścić dużych numerów inode. Tak więc domyślnie XFS ogranicza alokację węzłów do pierwszych grup alokacji, aby zapewnić, że wszystkie numery inodów są dopasowane do 32 bitów. Może to jednak mieć znaczący wpływ na wydajność i może zostać wyłączone przy użyciu opcji montowania inode64.

Skalowalność we/wy

Od pierwszego dnia system XFS został zaprojektowany z myślą o wydajnych podsystemach dyskowych, w szczególności paskach dyskowych o dużej łącznej szerokości pasma. Kiedy zaprojektowano technologię XFS, “wysoka wydajność” oznaczała kilkaset megabajtów na sekundę, ale 15 lat później XFS nadal działa z łączną przepustowością w dziesiątkach gigabajtów na sekundę dla pojedynczej instancji systemu plików [4]. Aby zapobiec zajęciu tablicy RAID, system plików powinien składać żądania We / Wy, które są wystarczająco duże, aby rozciągnąć wszystkie dyski w tablicy. Ponadto, we właściwych przypadkach, żądania We / Wy powinny być dopasowane do granic pasków, aby uniknąć cykli odczytu-modyfywrite dla powszechnych wzorców użycia. Ponieważ pojedyncze I / O może być tak duże, jak przylegający do siebie zakres bloków, kluczowe znaczenie ma przydzielanie plików tak daleko idących, aby umożliwić wysyłanie dużych żądań We / Wy do magazynu. Kluczem do osiągnięcia dużych, ciągłych regionów jest metoda znana jako “opóźniona alokacja”. W przypadku opóźnionego przydziału określone miejsca dysku nie są wybrane, gdy jest buforowany zapis; odbywa się tylko rezerwacje w pamięci. Rzeczywiste bloki dysku nie są wybierane przez alokatora, dopóki dane nie zostaną wysłane na dysk z powodu ciśnienia pamięci, okresowych zapisów lub wyraźnego żądania synchronizacji. Z opóźnieniem alokacji jest znacznie lepsze przybliżenie rzeczywistego rozmiaru pliku przy podejmowaniu decyzji o umieszczeniu bloków na dysku. W najlepszym przypadku cały plik może być w pamięci i może być przydzielony w jednym sąsiadującym obszarze. W praktyce XFS ma tendencję do przydzielania sąsiednich regionów od 50 do 100 GiB przy dużych dużych sekwencyjnych I / O, nawet jeśli wiele wątków zapisuje się w tym samym systemie plików [4]. Podczas gdy opóźnione przydziały pomagają w losowych nakładach na pisanie, jeśli przed napełnieniem dysku są wystarczająco duże obszary ciągłe, wciąż jest wiele workload, jeśli tak nie jest. Aby uniknąć rozdrobnienia w przypadkach patologicznych z losowymi zapisami, które napełniają plik bardzo wolno (np. Niektóre obciążenia HPC lub klienci BitTorrent), XFS umożliwia wstępne przydzielanie bloków na dysku do pliku przed jego zapisaniem. Prealokacja tylko przydziela bloki danych do pliku bez dotykania zawartości bloku. Aby uniknąć problemów z bezpieczeństwem w ujawnianiu nieaktualnych danych, przedziały alokowane są oznaczone jako niepisane, a wszystkie odczytywane z nich zwracają wartości zerowe. Gdy dane są zapisywane w niezapisanych zakresach, są one konwertowane do normalnych rozmiarów, co powoduje niską wydajność w porównaniu do zapisu do normalnego przydziału. Na rysunkach 3 i 4 pokazano poprawę wydajności, gdy XFS jest porównywany z ext3, starym standardowym systemem plików Linux i ext4, co powoduje zwiększenie opóźnień przydziałów i rozszerzeń do kolejnych obciążeń I / O. Z drugiej strony, na rysunku 5 pokazano, że wydajność dla całkowicie przypadkowego we / wy jest nie tylko zła, ale też nie przynosi zysków z funkcji XFS.

Bezpośrednie we / wy

XFS udostępnia funkcję zwaną Bezpośrednie I / O, która zapewnia semantykę surowego urządzenia UNIX wewnątrz obszaru nazw systemu plików. Odczytuje i zapisuje do pliku otwartego dla bezpośredniego obejścia we / wy obejścia pamięci podręcznej plików jądra i przejścia bezpośrednio z bufora użytkownika do podstawowego urządzenia we / wy. Pominięcie bufora plików oferuje pełną kontrolę nad rozmiarem żądania We / Wy i zasadą buforowania. Unikanie kopiowania w przestrzeni adresowej jądra zmniejsza znacznie zużycie procesora dla dużych żądań We / Wy. Dzięki temu I / O umożliwia bezpośrednie aplikacje, takie jak bazy danych, które tradycyjnie używały surowych urządzeń, działały w hierarchii systemów plików.
Bezpośrednie we / wy zostały przyjęte przez wszystkie główne systemy plików Linux, ale wsparcie poza XFS jest raczej ograniczone. Podczas gdy XFS gwarantuje niezakłócony zachowanie we / wy, niezależnie od okoliczności, inne systemy plików zwracają się do buforowanych we / wy dla wielu nietypowych przypadków, takich jak dołączanie zapisów, wypełnianie otworów lub pisanie na wstępnie przypisane bloki. Duża różnica semantyczna między bezpośrednim I / O i buforowanym plikiem I / O w XFS polega na tym, że XFS umożliwia wielokrotne pisanie plików przy użyciu bezpośredniego we / wy zamiast nakładania limitu pojedynczego pisaka określonego w programie Posix w celu buforowania we / wy. Szeregowanie żądań We / Wy uderzających w ten sam region pozostaje dla aplikacji, dzięki czemu bazy danych mogą uzyskać dostęp do tabeli w pojedynczym pliku równolegle z wielu wątków lub procesów.

Odzyskiwanie awarii

W dzisiejszych dużych systemach plików pełne sprawdzenie systemu plików w przypadku nieczystego zamknięcia systemu nie jest do zaakceptowania, ponieważ zajmie to zbyt długo. Aby uniknąć konieczności regularnego sprawdzania systemu plików, XFS korzysta z schematu rejestrowania przed zapisaniem, który umożliwia aktualizację atomową systemu plików. XFS rejestruje tylko aktualizacje strukturalne metadanych systemu plików, ale nie rzeczywiste dane użytkownika, dla których interfejs systemu plików Posix nie dostarcza przydatnych gwarancji atomowych. XFS rejestruje każdą aktualizację struktur danych systemu plików i nie zmienia partii z wielu transakcji do pojedynczego dziennika, tak jak to robi ext3. Oznacza to, że XFS musi pisać znacznie więcej danych do dziennika, jeśli pojedyncza metadana zostanie zmodyfikowana w krótkim ciągu (na przykład, usuwając dużą liczbę małych plików). Aby złagodzić wpływ zapisów dzienników na wydajność systemu, można użyć zewnętrznego urządzenia dziennika. Z zewnętrznym dziennikiem dodatkowe szukania na głównym urządzeniu są redukowane, a dziennik może korzystać z pełnej sekwencyjnej wydajności urządzenia rejestrującego. Niestety, rejestrowanie transakcji nie pomaga chronić przed błędami powodowanymi przez sprzęt. Aby rozwiązać te problemy, XFS posiada narzędzie do sprawdzania i naprawiania plików offline, o nazwie xfs_repair. Aby zmierzyć się z rosnącymi rozmiarami dysków i pogarszaniem się oczekiwań, w ostatnich latach firma xfs_repair przeszła znaczny remont, aby skutecznie czytać i buforować dane oraz korzystać z wielu procesorów w systemach SMP.

Kwoty dyskowe

XFS zapewnia lepszą implementację limitów dysku BSD. Obsługuje normalne miękkie i twarde ograniczenia dotyczące wykorzystania przestrzeni dyskowej i liczby inodes jako integralnej części systemu plików. Obsługiwane są zarówno kontyngenty na użytkowników, jak i grupowe obsługiwane przez BSD i inne systemy plików Linux. Poza kontyngentami grupowymi, XFS alternatywnie może wspierać kwoty projektu, w których projekt jest dowolnym identyfikatorem całkowitym przypisanym przez administratora systemu. Mechanizm limitów projektów w systemie XFS jest używany do implementacji kontyngentu drzewa katalogów, w którym podany katalog i wszystkie podkatalogi znajdujące się pod nim są ograniczone do korzystania z podzbioru dostępnej przestrzeni w systemie plików. Na przykład sekwencja poniżej ogranicza rozmiar plików dzienników w pliku /var/log do 1 gigabajta:

# mount -o prjquota / dev / sda6 / var
# echo 42: / var / log >> / etc / projects
# echo logfiles: 42 >> / etc / projid
# xfs_quota -x -c ‘project -s logfiles’ / var
# xfs_quota -x -c ‘limit -p bhard = 1g logfiles’ / var

Kolejnym udoskonaleniem wdrożenia kontyngentu XFS jest to, że podsystem przydziału rozróżnia rachunkowość kwotową i egzekwowanie kwot. Rachunek przydziałów musi być włączony podczas montowania, podczas gdy wymuszenie kwot może być włączane i wyłączane w czasie wykonywania. Korzystanie z systemu plików XFS z kontyngentem przydziału, ale egzekwowanie nie stanowi efektywnego sposobu monitorowania użycia dysku. Z tego powodu system XFS obsługuje również kwoty (ale nigdy nie wymusza) limitów użycia dla superużytkownika. Polecenie xfs_quota [8] przedstawione w powyższym przykładzie zapewnia pełny dostęp do wszystkich funkcji implementacji limitu XFS. Ponadto do zarządzania podstawową funkcjonalnością przydziału można używać standardowej kontyngentu BSD i narzędzi edquota.

Nieprzerwane używanie

Używany system plików powinien być nudny i niewidoczny dla administratora systemu i użytkownika. Aby uzyskać dostęp do tego stanu, należy najpierw utworzyć system plików. System plików XFS jest tworzony za pomocą polecenia mkfs.xfs, co jest trywialne w użyciu:

# mkfs.xfs / dev / vg00 / scratch
meta-data = / dev / vg00 / zarys isize = 256 agcount = 4, agsize = 1245184 blks = sekw = 512 attr = 2
dane = bsize = 4096 blocks = 4980736, imaxpct = 25 = sunit = 0 śr. = 0 blks
nazewnictwo = wersja 2 bsize = 4096 ascii-ci = 0
log = log wewnętrzny bsize = 4096 blocks = 2560, version = 2
= sekw = 512 sunit = 0 blks, lazy-count = 0
realtime = brak extsz = 4096 blocks = 0, rtextents = 0

Jak widać powyżej, polecenie mkfs.xfs zwraca informacje o geometrii systemu plików, aby upewnić się, że wszystkie parametry są prawidłowo ustawione. Nie ma wielu parametrów, które muszą być ręcznie ustawione do normalnego użytkowania. W przypadku macierzy RAID oprogramowania XFS już wyodrębnia prawidłowe wymiary paska i parametry wyrównania z podrzędnego urządzenia, ale jeśli nie jest to możliwe (na przykład dla kontrolerów sprzętu RAID), parametry można ustawiać ręcznie. Poniższy przykład tworzy system plików prawidłowo wyrównany do macierzy RAID5 z dyskami 8 + 1 i paskiem 256 kilobajtów:
# mkfs.xfs -d su = 256k, sw = 8 / dev / sdf
Inne interesujące opcje to użycie zewnętrznego urządzenia logującego i zmianę wielkości inode. Poniższy przykład tworzy system plików zawierający 2 kiB-size i zewnętrzne urządzenie rejestrujące:
# mkfs.xfs -i rozmiar = 2048 -l logdev = / dev / vg00 / logdev / dev / vg00 / home
Poleceniem warte uwagi jest xfs_fsr. FSR oznacza reorganizator systemu plików i jest XFS równoważny narzędziemu Defragmentacji systemu Windows. Umożliwia defragmentację listy zakresów wszystkich plików w systemie plików i może działać w tle z poziomu crona. Może być również używany w jednym pliku. Pomimo, że wszystkie ogólne aplikacje do tworzenia kopii zapasowych mogą być używane w systemach plików XFS, polecenie xfsdump jest przeznaczone specjalnie do tworzenia kopii zapasowych plików XFS. W przeciwieństwie do tradycyjnych narzędzi zrzutu, takich jak dumpe2fs dla ext2 i ext3, xfsdump używa specjalnego interfejsu API w celu wykonywania operacji we / wy na podstawie uchwytów plików, podobnych do tych używanych w protokole NFS przez protokół przewodowy. W ten sposób xfsdump nie cierpi z powodu niespójnych migawek urządzeń na surowym urządzeniu blokującym, które plują tradycyjne narzędzia do zrzutu. Polecenie xfsdump może wykonywać kopie zapasowe w regularnych plikach i taśmach na lokalnych i zdalnych systemach oraz obsługuje przyrostowe kopie zapasowe dzięki zaawansowanemu systemowi zarządzania zapasami. Systemy plików XFS mogą być uprawiane podczas instalacji przy użyciu polecenia xfs_growfs, ale nie można jeszcze zmniejszyć.

Wniosek

W tym artykule przedstawiono szybki przegląd funkcji XFS, systemu plików Linux dla dużych systemów pamięci masowej. Mam nadzieję, że jasno wyjaśnia, dlaczego Linux potrzebuje systemu plików, który różni się od domyślnego, a także pokazuje zalety systemu plików zaprojektowanego dla dużych magazynów od pierwszego dnia.