Systemy plików z kroniką

Kronika

Cel. Aby zlikwidować część wad tradycyjnych systemów plików w wielu nowoczesnych systemach zastosowano technikę kronikowania (ang. journalling lub logging). Kronika jest specjalnym plikiem przeznaczonym tylko do dopisywania. Zapisuje się ją sekwencyjnie, dużymi partiami, zwykle całą ścieżkę naraz. Kronika umożliwia szybkie postawienie systemu po awarii.

Rodzaje kronik Jest wiele rodzajów kronik:

Co zapisywać w kronice?	Są dwie możliwości zapisywania: wszystkich modyfikacji zmian wybranych metadanych (można wybrać tylko te operacje, które wpływają na spójność systemu)
Zapisywać operacje czy wartości?	Można zapisywać operacje albo ich wyniki.
Kronika jako dodatek czy zastąpienie	Można stosować kronikę jako uzupełanienie (Sysytemy plików rozszerzone o kronikę (ang. Logging enhanced file systems)) albo jako jedyną reprezentację systemu plików na dysku (Systemy plików o strukturze kroniki (ang. log-structured file systems)).
Kroniki z informacją do przywracanmia i anulowania	Są dwa typy kronik: tylko do przywracania (ang. redo-only), w której zapamiętuje się tylko zmodyfikowane dane. Dla tej kroniki wymagane jest zachowywanie porządku zapisywania danych. do anulowania przywracania (ang. undo-redo), w której zapamiętuje się zarówno stare, jak i nowe dane.
Odśmiecanie	Kronikę zwykle traktuje się jako plik cykliczny. Odśmiecać można wykonywać w czasie normalnego działania systemu lub za pomocą odrębnej operacji.
Grupowanie	Konieczny jest kompromis między rozmiarem zapisywanych porcji danych oraz częstością zapisu (więcej $\Rightarrow$ szybciej, częściej $\Rightarrow$ w razie awarii tracimy mniej danych).
Pobieranie danych	Konieczne jest zastosowanie efektywnego mechanizmu indeksowania, umożliwiającego odnalezienia w kronice dowolnego pliku (aby obsłużyć błędy braku strony).

Zalety. Zapisy na dysk dużych porcji - bardzo szybkie. Usuwanie skutków awarii jest również szybkie.

Wady. Odczyt jest wolniejszy (trzeba wyszukiwać ostatnio zmodyfikowane dane w kronice). W systemie, który działa już jakiś czas można z łatwością osiągnąć współczynnik trafień ponad 90%, jednak na początku, w wypadku bloków, które muszą być odczytane z dysku, trzeba zapewnić sposób odnajdowania ich w kronice.

System o strukturze kroniki: BSD-LFS

Opis. System 4.4BSD, znany pod nazwą BSD-LFS, zaprojektowano na podstawie wyników prac nad systemem Sprite. System BSD-LFS przeznacza cały dysk na kronikę, która jest jedyna trwałą reprezentacją systemu plików. Wszystkie zapisy umieszcza się na końcu kroniki, a odśmiecanie wykonuje proces cleaner. Kronika podzielona jest na segmenty stałego rozmiaru (zwykle 500 KB) połączone w listę.

Segmenty częściowe

Nie zawsze można zapisywać całkowicie wypełnione segmenty (np. gdy zabraknie pamięci podręcznej), dlatego wprowadza się segmenty częściowe (ang. partial segments). Każdy segment częściowy ma nagłówek, który zawiera następujące informacje:

• sumy kontrolne,
• adresy dyskowe każdego iwęzła w segmencie częściowym,
• numer i-węzła i jego wersji oraz numery logiczne bloków dla każdego pliku, który ma bloki danych położone w segmencie
• czas utworzenia, znaczniki, etc.

Rysunek: Schemat działania systemu plików BSD-LFS.

Mapa i-węzłów i tablica użycia segmentów

Zachowano strukturę katalogów i i-węzłów. Utrzymuje się mapę i-węzłów (ang. inode map), która przechowuje adresy dyskowe wszystkich i-węzłów. Mapa ta jest w pamięci fizycznej, ale zapisuje się ją do kroniki w okresowych punktach kontrolnych (ang. checkpoints).

System utrzymuje także tablicę użycia segmentów (ang. segment usage table), która przechowuje liczbę nieprzestarzałych bajtów i czas ostatniej modyfikacji dla każdego segmentu.

Operacje wejścia-wyjścia

Zapis. System BSD-LFS zbiera zabrudzone dane tak długo, aż będzie ich wystarczająco do zapełnienia segmentu. Wówczas wszystkie zabrudzone dane są zapisywane, a kronika zawiera wszystkie dane do pełnego usunięcia skutków awarii.

Odczyt. W celu umożliwienia sprawnego odczytu, potrzebna jest duża pamięć podręczna, tak aby większość zleceń można było realizować bez dostępu do dysku. W pamięci podręcznej bloki są identyfikowane i haszowane za pomocą v-węzła i logicznego numeru bloku. Ważna jest także obsługa błędu braku strony w sensownym czasie. I-węzły wyszukuje się w mapie i-węzłów.

Usuwanie skutków awarii

Usuwanie skutków awarii przebiega następująco:

1. odnalezienie ostatniego punktu kontrolnego
2. zainicowanie mapy i-węzłów i tablicy użycia segmentów
3. przeglądanie i wykonywanie tych zmian, które nastapiły po zapisaniu ostatniego punktu kontrolnego.
4. suma kontrolna w nagłówku zapewnia, że segment częściowy jest kompletny. Jeśli nie, to jest to ostatni segment i jest on odrzucany.

Cleaner

Zadaniem procesu cleaner jest gromadzenie aktywnych danych z segmentów, przenoszenie ich w nowe miejsce i w ten sposób odzyskiwanie semgnetów. Cleaner

1. wybiera segment do czyszczenia (korzysta z tablicy użycia segmentów),
2. wczytuje segment do czyszczenia do swojej przestrzeni adresowej,
3. wybiera i-węzły i bloki, które są aktywne (korzysta z mapy i-węzłów),
4. zapisuje je w innym segmencie częściowym,
5. zaznacza segment czyszczony jako wolny.

Rysunek: Schemat działania procesu cleaner w systemie plików BSD-LFS.

Systemy z kronikowaniem metadanych

Zyski i wady. Kronikowanie tylko metadanych:

• Upraszcza implementację, gdyż nie trzeba zmieniać implementacji operacji, które nie zmieniają struktury systemu plików. Jedyne, co trzeba zrobić, to zapisywać do kroniki.
• Umożliwia szybkie odtworzenie systemu po awarii.
• Przyspiesza operacje na metadanych dzięki gromadzeniu operacji, które wykonują wiele zmian metadanych (np. mkdir) w jeden zapis w kronice i zmniejszeniu liczby synchronicznych zapisów na dysk. Ta oszczędność powinna niwelować narzut związany z prowadzeniem kroniki.
• (!)Nie ogranicza strat w danych z plików.

Organizacja kroniki. Jest wiele wariantów organizackji kroniki:

• System Cedar. Plik zwykły, cykliczny, o ustalonym rozmiarze.
• System Calaveras. Wszystkie systemy plików współdzielą jedną kronikę, która znajduje się na osobnym dysku.
• System Veritas. Kronika oddzielona od systemu plików, może być na osobnym dysku.

Badania. System plików z kroniką jest znacznie szybszy, gdy wykonuje się wiele operacji na metadanych. W przeciwnym przypadku szybkość jego działania jest porównywalna do zwykłych systemów plików.

System plików Episode

Powstanie. System plików Episode (ang. Episode File System) powstał jako rozwinięcie systemu plików Andrew (AFS). Stał się on lokalnym systemem plików w rozproszonym środowisku obliczeniowym (ang. DCE - Distributed Computing Environment).

Możliwości. System udostępnia kilka złożonych możliwości, których nie mają tradycyjne uniksowe systemy plików. Są to m.in:

• rozszerzone mechnizmy zabezpieczeń
• wsparcie dla dużych plików
• kronikowanie
• oddzielenie abstrakcji dotyczących pamięci masowej od logicznej struktury systemu plików

Organizacja. Do systemu plików Episode wprowadzono pojęcia:

• agregaty (ang. aggregates) - zbiór bloków na dysku, logicznie ciągły (uogólnienie partycji). Fizycznie może składać się z kilku partycji. Zatem umożliwia tworzenie plików o rozmiarze większym niz rozmiar dysku.

• zestawy plików (ang. filesets) - logiczny system plików, drzewo katalogów. Jeden agregat może zawierać wiele zestawów plików, które można niezaleznie montować, demontować, przenosić do innego agregatu.

• a-węzły (ang. anodes) - odpowiedniki i-węzłów. W Episode mamy dokładnie po jednym a-węźle dla każdego pliku i każdego kontenera.

• kontenery (ang. containers) - obiekt przechowujący dane. Składa się z bloków. Każdy zestaw plików mieści się w kontenerze, który gromadzi wszystkie metadane i dane tego zestawu. Konterery nie zajmują ciągłych obszarów w agregacie, mogą więc rosnąć i kurczyć się. Wszystkie a-węzły są umieszczone w tablicy a-węzłów zestawu plików (ang. fileset anode table) znajdującej się na początku kontenera. Za nimi znajduja się dane i bloki pośrednie. Każdy agregat ma trzy dodatkowe kontenery:
  1. Kontener na mapę bitową. Informacja dla każdego fragmentu - czy jest przydzielony i czy jest kronikowany.
  2. Kontener na kronikę. Zawiera kronikę metadanych dla tego agregatu. Zwykle znajduje się w agregacie (ale nie musi tak być).
  3. Kontener na tablicę zestawów plików. Tablica zawiera superblok i a-węzły dla każdego zestawu plików w agregacie.
  Kontenery zezwalają na trzy tryby przechowywania danych:
  1. wplecione (ang. inline) - każdy węzeł ma dodatkową przestrzeń, przydatne dla linków symbolicznych, kontroli dostępu, itd.
  2. fragmentowe (ang. fragmented) - kilka małych kontenerów moze współdzielic jeden blok dysku
  3. blokowe (ang. blocked) - wspiera cztery poziomy pośredniości

Rysunek: Schemat działania systemu Episode .

Rysunek: Schemat działania systemu Episode.

Kronika w systemie plików Episode. Kronika zawiera informacje o przywracaniu i anulowaniu (tj. stare i nowe wartości), która zapewania silna transakcyjną (albo cała operacja albo nic) gwarancję spójności. To rozwiązanie wymaga dwufazowego protokołu nakładania blokady (ang. Twopfase locking): nakłada się blokadę na wszystkie obiekty, których dotyczy transakcja, dopóki cała transakcja nie zostanie zatwierdzona. Dzięki temu żadna inna transakcja nie jest w stanie odczytać niezatwierdzonych danych.

Klonowanie. Można klonować zestawy plików (kopiuje się metadane, a dane plików są dzielone). Operacja ta jest szybka. Sklonowany zestaw plików jest tylko do odczytu (jest jednak aktualizowany) i przydaje się np. w narzędziach administracyjnych.

Systemy plików z dozorcą

Zarys problemu. Chcemy w jednolity sposób związać z pewnymi plikami specjalne sposoby obługi dostępu do nich. Na przykład:

1. podejmowanie automatycznych akcji przy odbiorze poczty
2. przechowywanie danych w postaci skompresowanej i autmatyczne rozpakowywanie przy odczytcie
3. kronikowanie / nadzorowanie dostępów do konkretnegio pliku

Wprowadzenie programów dozorujących. Z każdym plikiem związujemy (na żądanie) proces przechwytujący operacje wejscia-wyjscia na tym pliku, zwany procesem dozorcy (ang. watchdog). Wykonuje się to za pomocą funkcji systemowej: wdlink (nazwa pliku, nazwa programu dozorcy w katalogu /wdogs). Plik staje się plikiem dozorowanym (ang. guarded file).

Gdy dowolny proces zechce dobrać się do pliku dozorowanego, jądro przekazuje sterowanie do procesu dozorcy (uruchamiając go być może), który podejmuje decyzję. Jeśli dozorca pozwala na otworzenie pliku, pokazuje jakich operacji nalezy użyć (mogą to być nawet różne operacje dla różnych otwartych egzemplarzy tego samego pliku).

Rysunek: Schemat działania systemu z dozorcą.

Dozorowanie katalogów. Można dozorować również katalogi(!). Daje to możliwość tworzenia iluzji plików, których nie ma.

Kanały komunikacyjne. Komunikację między dozorcą obsługuje się za pomocą kanałów komunikacyjnych (ang. WMC - Watchdog Message Channel), tworzony za pomocą funkcji systemowj createwmc, która zwraca deskryptor kanału. Każdy komunikat ma pole typu, identyfikator sesji i właściwą treść. Każdy otwarty plik rozpoczyna unikatową sesję z dozorcą.

Przebieg komunikacji:

1. Wywołanie funckji wystemowej createwmc. Tworzy kanał WMC (plik) i zwraca jego deskryptor.
2. Dozorca odczytuje komunikaty i wysyła odpowiedzi używając deskryptora kanału. Ma dostęp do kolejki komunikatów poprzez ten deskryptor.

Rysunek: Schemat działania systemu z dozorcą.

Zastosowania W pierwotnej wersji wprowadzono kilka ciekawych zastosowań:

wdacl	Związuje z plikiem listę kontroli dostępu (ACL).
wdcompact	Kompresja / dekompresja w locie.
wdbiff	Automatyczne akcje dla skrzynki pocztowej.
wdview	Prezentuje różnym użytkownikom różną postać tego samego katalogu.
wddate	Pozwala na odczytanie bieżącego czasu i daty.

Systemy plików z portalem

Funkcjonalność System plików z portalem (ang. Portal File System) oferuje podobną funkcjonalność jak dozorcy. W systemie działa demon portalu (ang. portal daemon), który obsługuje zlecenia otwarcia plików i przydziela deskryptory. Demon portalu ma unkisowe gniazdgo, na którym nasłuchuje (wywołuje accept-y).

Przebieg komunikacji Proces użytkownika zechce otworzyć nowy plik w systemie plików z portalem. Prosba zostaje przekazana do demona portalu, który określa i zwraca deskryptor nowego pliku.

Stosy systemów plików

Analogia z Wirualnym Systemem Plików

Tworzeniu Stosowych warst systemu plików przez UCLA (University of California) i firmę SunSoft przyświecała analogia z przykryciem konkretnych systemów plików przez wirtualny.

Rysunek: Schemat działania systemu z dozorcą.

Możliwości. Mechanizm stosowego nakładania systemów plików pozwala montować wiele systemów plików na drugim. Wirtualny v-węzeł jest - fizycznie - stosem węzłów kolejnych warstw systemów plików.

Przykład. Producent chce dostarczyć moduł szyfrowania-deszyfrowania. Wystarczy umieścić go na wierzchu systemu plików - moduł będzie przechwytywał wsystkie operacje we-wy i przekazywał (po zaszyfrowaniu lub zdeszyfrowaniu) operacje warstwę niżej.

4.4BSD. W systemie 4.4.BSD funkcja systemowa mount odkłada nową warstwę systemu plików na stos v-węzła, a umount zdejmuje. Każdą operację przekazuje się najpierw do warstwy znajdującej się na wierzchu. Każda warstwa może albo zakończyć wykonywanie się operacji albo przekazać ją do niższej warstwy. Jeżeli warstwa nie rozpoznała operacji przekazuje ją do warstwy niższej za pomocą funckji bypass

System plików nullfs

System plików nullfs pozwala zamontować dowolne poddrzewa hierarchii plików w dowolnym miejscu w systemie plików. Powoduje to skutek taki, jak dostarczenie drugiej nazwy ścieżkowej dla każdego pliku w poddrzewie. Nullfs przekazuje operacje do piewrwotnego systemu plików.

System plików union mount

Oferuje funkcjonalność podobną do TFS-a. Umożliwia uzyskanie łącznego obrazu (unii) wszystkich systemów plików zamontowanych pod warstwą union mount. Wierzchnia warstwa jest najnowasza i tylko do niej można zapisywać. Gdy użytkownik szuka pliku, system przeszuka warstwy poczynając od wierzchniej.