System plików VERITAS (znany także pod nazwą VxFS) powstał pod koniec lat 80-tych zeszłego stulecia. Obecnie jest jednym z najlepszych komercyjnych systemów plików dla systemów Unixowych - istnieją wersje dla SOLARISA, HP-UX, AIX oraz Linuxa i większości mikrojąder unixowych. Komercyjność tego systemu polega na tym, że nie jest on (niestety) darmowy; oprócz zakupu samego systemu plików (jak i wielu innych narzędzi software'owych tworzących, jak to się dziś ładnie mówi, rozwiązania biznesowe) firma Veritas Software oferuje także przeróżne szkolenia, pomoc techniczną itp.
Oto najważniejsze cechy systemu plików VERITAS:
Przyjrzyjmy się tym cechom nieco bliżej.
Większość tradycyjnych Unixowych systemów plików alokuje za pomocą bloków. Jeśli blok jest rozmiaru 4KB, a rozmiar pliku wynosi 16KB, to ten plik bedzie się składał z 4 bloków. W tradycyjnej metodzie alokacji plików duży plik zostanie podzielony na bloki, do których dostęp będzie pośredni, podwójnie pośredni, a nawet potrójnie pośredni. To podejście ma dwie zasadnicze wady:
VxFS jest systemem plików, który alokuje w oparciu o extenty (zdecydowano się na pozostawienie pisowni oryginalnej, bez tłumaczenia). Niezależnie od rozmiaru bloku wybranego dla VxFS'a (1KB, 2KB, 4KB czy 8KB), dane mogą być zaalokowane w większych, ciągłych obszarach, zwanych extentami. Minimalny rozmiar extentu jest równy rozmiarowi bloku. Może się jednak zdarzyć, że reprezentacja pliku na dysku będzie się składała z tylko jednego extentu.
Jeśli tworzymy plik, którego rozmiar jest znany, możemy na to przygotować system plików poleceniem 'setext'. Jeśli będzie to możliwe, zaalokowany zostanie jeden extent. W przypadku, gdy tworzymy plik o początkowo nieznanym rozmiarze, zaalokowany zostanie extent o wielkości najbliższej potęgi dwójki bloków większej niż rozmiar pierwszej porcji zapisu do tego pliku. Następnie zwiększany jest rozmiar extentu, o ile zachodzi taka potrzeba i nadal jest to możliwe, wpp. tworzony jest nowy extent.
Po zamknięciu pliku, jeśli okazało się, że zapisany jest jedynie fragment jakiegoś extenta, extent jest skracany a jego wolna część jest zwalniania.
Przykład: tworzenie nowego pliku o ustalonej wielkości (rozmiar bloku - 1KB, rozmiar pliku - 1MB):
Opcja '-e' oznacza, że do alokacji tego pliku chcemy używać extentów o stałej wielkości. Opcja '-r' powoduje prealokację przestrzeni dla pliku (w tym przypadku powinien być przydzielony 1 extent zawierający 1024 bloki). Opcja '-f chgsize' oznacza, że zarezerwowanie miejsca ma się odbyć natychmiast.
Na poniższym obrazku widzimy, że otrzymany efekt jest zgodny z zamierzeniami (de - direct extent, des - direct extent size). Pogrubiona opcja 'reserve 1024' oznacza, że jeśli nawet plik będzie skrócony, to jego i-węzeł ulegnie zmianie, ale plik w dalszym ciągu będzie się składał ze starej liczby bloków.
VxFS korzysta z narzędzi wspomagających cache'owanie. Kontrolują one sposób wykonania operacji I/O na pliku. Do narzędzi tych należą: bezpośrednie I/O, niebuforowane I/O, synchroniczne I/O. Ponadto VxFS wprowadza odkryte I/O (ang. discovered direct I/O), podobne do bezpośredniego I/O, choć wykonywanego bez udziału użytkownika.
VxFS umożliwia określenie limitu dla użytkowników i grup zarówno jeśli chodzi o liczbę zaalokowanych plików jak i liczbę używanych bloków. Istnieją dwa typy ograniczeń:
VxFS udostępnia trwałe (ang. checkpoints) jak i nietrwałe kopie zapasowe (ang. snapshots). Główna różnica polega na tym, że trwałe są odporne na restarty komputera, a nietrwałe nie.
To co wyróżnia VxFS wśród systemów plików, to niemożność spowodowania błędu typu "panic". W momencie wykrycia błędu I/O, VxFS ogranicza dostęp do konkretnych struktur systemu plików, podczas gdy pozostałe są wciąż dostępne. Na przykład, przy czytaniu informacji o i-węźle, VxFS sprawdza jego poprawność (tzn. czy struktura jest spójna). Jeśli test poprawności się nie powiedzie, i-węzeł jest oznaczany jako zepsuty i zostaje ustawiona odpowiednia flaga, powodująca uruchomienie procesu sprawdzającego cały dysk ('fsck'). Możliwy jest jednakże dostęp do pozostałej części systemu plików.
Ta polityka spowodowała pojawienie się pewnych problemów wraz z wprowadzeniem łączy światłowodowych i systemów globalnych. Zbyt często, po odłączeniu łączy, pojawiały się tymczasowe błędy I/O i zbyt często pracował proces 'fsck'.
Polityka obsługi błędów I/O została więc ułagodniona. Administratorzy uzyskali większą elastyczność przy konfiguracji obsługi błędów I/O. Istnieje możliwość podania parametru 'ioerror' podczas montowania systemu plików. Po napotkaniu błędu I/O można np. unieruchomić cały system plików w celu odmontowania i naprawy błędu, pozostać przy standardowej polityce, czy podzielić dopuszczalne błędy na błędy odczytu, a zatrzymywać całość przy błędach zapisu. To ostatnie ma także podział na błędy zapisu danych i metadanych.
VxFS radzi sobie także jako system z klastrami. Zainteresowanych odsyłamy do pozycji wymienionych na końcu dokumentu.
Układ danych na dysku systemu VxFS zmieniał się wraz z wersjami systemu. Powstało 5 różnych wersji layoutów. Pierwsza przypominała layout z systemu UFS (patrz rysunek). Obecna umożliwia tworzenie systemu plików o wielkości do 32TB oraz pojedynczych plików o rozmiarach do 2TB.
Podstawowe pojęcia:
Kronika (intent log) znajduje się bezpośrednio za superblokiem, a bezpośrednio przez pierwszą jednostką alokacji. Wszystkie (poza ewentualnie ostatnią) jednostki alokacji są tego samego rozmiaru, ustalonego w momencie tworzenia systemu plików.
Stały rozmiar jednostki alokacji powodował ograniczenia na liczbę i rozmiar pozostałych struktur systemu plików.
Piąta, najnowsza wersja układu rozwiązuje większość z tych problemów. Wszystkie metadane mogą rosnąć na żądanie. Wprowadzono także pojęcie partycji (ang. fileset), zaczerpnięte z rozproszonego systemu DCE (ang. Distributed File System), oraz pojęcie agregatu (ang. aggregate), będącego zbiorem partycji.
Przy tworzeniu systemu plików VxFS, tworzone są dwie partycje: główna, zawierająca dane, oraz pomocnicza, zawierająca metadane. Każda z obu partycji ma swoją listę i-węzłów, przechowywaną w pliku. Wszystkie metadane są przechowywane w plikach. Pliki metadanych to:
Na rysunku widzimy w jaki sposób system używa niektórych z tych struktur przy montowaniu systemu plików. Struktury zawarte są w plikach, więc system musi wiedzieć w jaki sposób uzyskać dostęp do tych plików. W celu podmontowania systemu plików, VxFS musi zlokalizować główny i-węzeł partycji danych. Wykonywane są następujące kroki:
Ponieważ wszystkie informacje strukturalne systemu plików znajdują się w plikach, początkowo alokuje się minimalną ilość informacji, np. tylko 32 i-węzły są alokowane przy tworzeniu systemu. Aby zwiększyć liczbę i-węzłów, rozszerza się plik listy i-węzłów wraz z jednostkami alokacji i-węzłów (bitmapami wolnych i-węzłów itp.). Ponadto, mapy extentów i podsumowań tworzone są tylko wtedy, gdy jest taka potrzeba.
Pojęcie jednostki alokacji zmieniło się w nowszych wersjach układów danych na dyskach. System plików jest podzielony na jednostki alokacji (AU) stałego rozmiaru, każda po 32KB bloków. AU 0 zaczyna się od bloku o numerze 0 systemu plików. Plik stanu AU zawiera po dwa (2) bity na każdą AU, wskazujące czy AU jest używana oraz czy została rozszerzona. Jeśli została rozszerzona, bitmapy extentów oraz podsumowań są alokowane w celu mapowania AU. Zauważmy, że jeśli potrzeba zaalokować pojedynczy blok 32KB, plik stanu AU jest uaktualniany w celu wskazania, że ta AU jest używana, ale nie ma potrzeby tworzenia bitmap. Mapowanie pomiędzy strukturami przy zarządzaniu AU oraz mapami extentów zaprezentowano na rysunku.
Przy tworzeniu systemu plików, początkowo używa się jednej lub dwóch AU. Określa się to w pliku stanu AU oraz rozszerza się odpowiadające podsumowania extentów i bitmapy. Ponieważ nie używa się żadnych innych AU, pozostałe struktury nie są alokowane. W momencie alokacji nowych plików używa się coraz więcej AU. Gdy chcemy wykorzystać nieużywane AU, uaktualnia się plik stanu, rozszerza się podsumowania i pliki bitmap oraz uaktualnia je o właściwą informację.
To tłumaczy dlaczego początkowa alokacja w systemie plików jest stała, bez względu na wielkość tworzonego systemu plików.
Przy tworzeniu systemu plików możemy albo zająć całą dostępną przestrzeń, albo wyspecyfikować konkretną wielkość w sektorach. Domyślnie, VxFS ustawia rozmiar bloku na 1024 bajty, niezależnie od wielkości systemu plików. Uznano to za najbardziej efektywną wartość.
Rozmiar kroniki jest obliczany automatycznie w oparciu o rozmiar systemu plików. Można też oczywiście podać własną wartość.
VxFS umożliwia odmontowanie systemu plików, nawet wtedy, gdy ten jest w użyciu. Jest to szczególnie ważne w środowiskach klastrowych o wysokiej dostępności, gdzie wykryto awarię i zachodzi potrzeba przełączenia na innego hosta. System plików zostaje odmontowany na starym hoscie, nowy host uruchamia proces naprawczy i montuje system plików. Na starym hoscie mogą istnieć procesy korzystające z systemu plików, wobec czego zwykła komenda 'umount' mogła by zwrócić błąd 'EBUSY'.
Powyższa możliwość jest dostępna w niewielu systemach UNIXowych, np. Solaris ma flagę 'force'.
Podczas awarii systemu, systemy plików są zazwyczaj uszkadzane strukturalnie. Uruchamiany jest wtedy proces 'fsck' naprawiający uszkodzone struktury. Systemy plików czy inne obszary jądra korzystające z I/O nie mogą zakładać, że operacje I/O są ukończone w momencie awarii. Każdy napęd dyskowy gwarantuje pewną wielkość zapisu, tzn. zapewnia, że będzie ona wykonana atomowo (odniesie sukces lub porażkę - napęd nie może zapisać mniejszej liczby danych). Jest to zazwyczaj wielkość 512 lub 1024 bajtów. Większość operacji na strukturze systemu plików wymaga jednak aktualizacji większej liczby struktur, tak więc mechanizm gwarantowanego zapisu jest niewystarczający.
Rozpatrzmy przypadek tworzenia pliku. Wymaga to następujących operacji:
Taki typ operacji wymaga aktualizacji pewnej liczby struktur, rozsianych po różnych blokach na dysku. Jeśli awaria systemu nastąpi po zapisaniu części z tych informacji, ale przed zakończeniem zapisu wszystkich informacji, system plików będzie niespójny. Rolą procesu 'fcsk' jest wykrycie i naprawienie takich niespójności wynikających z awarii. Dla przykładu, jeśli zaalokowano i zainicjowano już i-węzeł, ale nie podpięto go do katalogu, i-węzeł jest "sierotą" i zostanie przesunięty przez 'fsck' do katalogu 'lost+found' lub zostanie usunięty.
Czas pracy procesu 'fsck' jest proporcjonalny do ilości metadanych w systemie plików, i - co za tym idzie - do liczby istniejących plików. Jako, że coraz powszechniejsze są już systemy o wielkości mierzonej w terabajtach, takie rozwiązanie stało się niedopuszczalne - czas pracy procesu 'fsck' mógł wynosić dziesiątki godzin.
Rozwiązaniem tego problemu jest kronikowanie, tzn. opisywanie wszystkich takich operacji w metodologii transakcji (sukces lub porażka). Innymi słowy, system plików będzie spójny przez cały czas.
VxFS wszystkie aktualizacje na strukturze systemu plików wykonuje jako transakcje. Transakcja jest zapisem jednej lub więcej zmian na systemie plików. Zmiany są najpierw zapisywane do kroniki (która jest buforem cyklicznym zapisywanym w systemie plików), a dopiero następnie aplikowane do konkretnych lokalizacji na dysku. W powyższym przykładzie tworzenia pliku, wszystkie operacje stanowią jedną transakcję. W przypadku awarii systemu, proces 'fsck' ponowi wykonanie zawartości kroniki w celu ukończenia aktywnych transakcji. Wszystkie zapisy w kronice mają własność idempotentności, tzn. mogą być nakładane na siebie dowolną liczbę razy bez zmiany wyniku. To zapewnia poprawność odtwarzania zapisów kroniki, nawet wówczas, gdy system ulegnie awarii w trakcie odtwarzania zapisów kroniki (taka ewentualność jest oczywiście możliwa).
Przy zapisywaniu transakcji do kroniki, umieszczane są dodatkowe znaczniki wskazujące początek i koniec transakcji. W przypadku awarii, uruchomiony zostanie proces 'fsck' i wykona wszystkie znalezione zapisy kroniki, które zawierają kompletne transakcje (awaria może też nastąpić w momencie zapisu transakcji do kroniki). Pierwsze zadanie polega na znalezieniu początku kroniki (bufor jest cykliczny) poprzez znalezienie najmniejszego 'ID' transakcji.
Następnie, każdy zapis jest odtwarzany, tj. wykonywany jest ciąg czynności zapisanych w transakcjach (idempotentność). Jest to kluczowa część formatu zapisu do logu. Dla przykładu akcja opisana jako 'zwiększ licznik odwołań do i-węzła o 1' nie ma własności idempotentności. Idempotentna jest np. własność 'ustaw licznik odwołań do i-węzła na 3'.
Rozmiar pliku kroniki jest wybierany przy tworzeniu systemu plików i nie może przekroczyć 16MB.
Pewne operacje stwarzają problemy przy systemie z kroniką. Dla przykładu, rozważmy wywołanie systemowe 'unlink()' dla pliku o liczniku odwołań równym 1. Po powrocie z wywołania 'unlink()', plik uważa się za skasowany. Problemy pojawiają się w momencie, gdy plik był równocześnie otwarty przez inny proces. W tym przypadku, plik nie może zostać fizycznie usunięty z dysku, zanim nie zostanie wykonana ostatnia operacja 'close' na tym pliku.
Aby złagodzić ten problem, VxFS dostarcza rozszerzone operacje na i-węźle (ang. inode extended operations). W powyższym przykładzie zostanie ustawiona operacja 'VX_IEREMOVE', wskazująca, że plik ma zostać usunięty. Stanowi ona sama w sobie transakcję. Każda próba otwarcia tego pliku zakończy się porażką, ale procesy wciąż mające otwarty plik mogą kontynuować pracę na tym pliku.
Po awarii systemu, rozszerzone operacje muszą zostać ukończone PRZED ponownym dostępem do systemu plików. W naszym przykładzie, plik musi zostać fizycznie usunięty.
VxFS korzysta z rozszerzonych operacji w szerokim zakresie, choć użytkownicy nie zdają sobie z tego sprawy.
Przez lata systemy UNIXowe borykały się z brakiem rozwiązań administracyjnych, które mogą być wykonywane w trakcie pracy zamontowanego systemu. Rozważmy przykład zmiany rozmiaru systemu plików. Tradycyjne rozwiązania wymagają następujących czynności:
Niepożądanym efektem jest tu przerwa w dostawie usługi. VxFS dostarcza mechanizmów, poprzez które możliwa jest zmiana rozmiaru (w dowolną stronę) systemu plików w trakcie pracy systemu. Całość odbywa się za pomocą kilku prostych poleceń. Firma Veritas udostępnia także zestaw narzędzi wspomagających ten i podobne procesy.
Podczas alokacji extentów dla plików, system próbuje wykonać to w najbardziej optymalny sposób. Jednakże, w czasie pracy, system plików ulega fragmentacji. Małe wolne (dostępne) extenty są rozsiane po systemie plików i powodują nieoptymalny wybór przy alokowaniu extentów do nowych plików. VxFS umożliwia redukcję fragmentacji w czasie pracy systemu. Proces ten wymaga zlokalizowania mapy extentów plików objętych fragmentacją i wykonania "reorganizacji extentów" na tych plikach, co powoduje próbę połączenia extentów w większe, tam gdzie to możliwe. To z kolei wymaga alokowania nowych extentów i kopiowania danych. Ponadto to samo próbuje się robić z wolną przestrzenią, umożliwiając lepsze, efektywniejsze alokacje w przyszłości.
Podobnie, poprzez alokowanie i usuwanie plików, fragmentacji mogą ulegać katalogi. Cały proces przebiega podobnie do wyżej opisanego.
VxFS stara się przystosować do środowiska, w którym przyszło mu pracować (tj. do ilości dostępnej pamięci, liczby procesorów, geometrii dysków itp.). Jednakże, niektóre aplikacje mogą wymagać konkretnych własności I/O kosztem innych własności, np. szybkości dostępu kosztem integralności danych.
Oto kilka opcji, które można podać przy montowaniu systemu plików VxFS. Pokazują one zakres skalowalności tego systemu.
Zmiana sposobu zarządzania kroniką: (1) domyślny, (2) zapis do loga z opóźnieniem, (3) zapis do loga tymczasowego, (4) brak zapisu zmian danych do loga.
W celu zapewnienia UNIXowej semantyki pliku, czytanie z pliku zmienia znacznik czasowy dostępu do i-węzła. Istnieje jednak kilka aplikacji, które muszą zobaczyć ten czas dostępu,. Opcja 'noatime' umożliwia ignorowanie aktualizacji tego znacznika o ile nie został zapisany przy aktualizacji czasu modyfikacji.
Własności cache'owania systemu plików mogą zostać zmienione podczas montowania poprzez określenie opcji 'mincache' lub 'convosync'. Opcje te umożliwiają administratorowi zakres ustawień pomiędzy maksymalną integralnością danych a maksymalną wydajnością, zależnie od obciążenia maszyny.
Opcje 'mincache': (1) zmiany w pliku są zapisywane w momencie zamykania pliku, (2) zmiany i-węzła z opóźnieniem jeśli zapis bez alokacji nowych extentów, (3) gwarancja zakończenia zapisu przed powrotem z wywołania funkcji systemowej, (4) podobnie do poprzedniej, ale gwarancja nie obejmuje aktualizacji i-węzła, (5) opóźnienia w wykonaniu prawie wszystkich operacji, tj. największa wydajność, ale najmniejsza integralność.
Opcje 'convosync': (1) zmiany w pliku są zapisywane w momencie zamykania pliku, (2) opóźnienia w zapisie, (3) zmiany zapisywane przy zamykaniu pliku oraz brak modyfikacji i-węzła, gdy aktualizowane były jedynie znaczniki czasowe, (4) zmiany zapisywane przy zamykaniu pliku, ale zmiany w i-węźle są asynchroniczne, (5) konwersja synchronicznego zapisu do synchronicznego zapisu danych, zmiany zapisywane przy zamykaniu pliku.
Opcja 'blkclear', gdy określona, zapewnia wypełnienie alokowanych extentów zerami; przeciwdziała to pojawieniu się niezainicjowanych danych w plikach. Powoduje to jednakże spadek wydajności (o ok. 10%).
Ukierunkowując zastosowanie dla systemów baz danych, VxFS wprowadza 'Szybkie I/O'.
Omówmy najpierw kwestie pracy systemów baz danych na systemach plików. Uproszczony schemat można znaleźć na poniższym rysunku.
Aby rozwiązać powyższe problemy, systemy baz danych rozwijają się w kierunku tzw. 'raw I/O', które usuwa problemy blokad systemu plików i dostarcza bezpośredniego I/O pomiędzy buforami i dyskiem. W ten sposób traci się jednak własności administracyjne systemu plików.
VxFS dostarcza własności 'Szybkie I/O'; umożliwia to uniknięcie powyższych problemów poprzez dostarczenie alternatywnej przestrzeni nazw. Rozważmy to na przykładzie alokacji pliku na potrzeby bazy danych. Tworzone są dwa pliki: jeden zwykły, o zadanej wielkości, drugi plik zaś jest linkiem symbolicznym. VxFS rozpoznaje, że ten plik powinien być obsługiwany w specjalny sposób:
Dzięki zastosowaniu Quick I/O bazy danych mogą osiągnąć najwyższą spotykaną dziś wydajność.
Kronika systemu VxFS jest fizycznie przechowywana w pobliżu początku dysku. Mimo, że zapisy do kroniki są sekwencyjne i minimalizują ruchy głowicy przy czytaniu i zapisie do kroniki, VxFS działa także na innych obszarach systemu plików, powodując ruchy głowicy od kroniki do reszty systemu plików. Aby zminimalizować całościowy ruch głowicy, VxFS wspiera możliwość przeniesienia kroniki na osobne urządzenie zwane QuickLog. Ze względów wydajnościowych QuickLog powinien znajdować się na innym dysku niż system plików.