Nowoczesne systemy plików Rafal@Wijata.com

Wady starych systemów plików Wydajność Dużo synchroniczne odwołań do dysku Rozłożenie (meta)danych nie pozwala na wykorzystanie pełnej prędkości dysku Duze katalogi Przywracanie spójności po krachu systemu Bufory plików implikują brak spójności Fsck trwa ~15min na 20GB SCSI Bezpieczeństwo Brak ACLów Limity rozmiarów 31bity = 2GB =  Duże klastry powodują niepotrzebne straty miejsca

Problemy do rozwiązania Czytanie Opóźnienia powodowane czytaniem porcjami Zapis Synchroniczne zapisy, zapisywanie na pierwszym planie Synchroniczny model NFSu Metadane Kasowanie pliku to kilka operacji na metadanych, wymagana kolejność (synchronizacja) lub atomowość Lepsze przywracanie spójności systemu plików

Księgowanie (logowanie) Najprościej – księguj wszystko, a będziesz wiedział co się działo w czasie pracy systemu Co logować ? całość, metadane, informacje o spójności, wyniki Dodatek, czy nowy FS ? Redo vs Redo-Undo Odśmiecanie Grupowe logowanie wzrost wydajności Szybkie odzyskiwanie danych indeksowanie logów

4.4BSD-Structured File System Cały wolumin dedykowany na logi Logujemy wszystko, każdą zmianę danych, razem z danymi Zapis Wszystko dopisywane na koniec logu = ultra szybki zapis Zapisywanie całych segmentów (½ MB) Segmenty mają własne nagłówki Odczyt Problem znajdowania danych Olbrzymi cache w pamięci Mapa i-węzłów w pamięci, logowana co jakiś czas Wpisy katalogów mają numery i-węzłów następnych.

Przywracanie spójności 4.4BSD – LFS Przywracanie spójności Odczyt ostatniej mapy i-węzłów, ponowne wykonanie możliwych operacji po tym czasie. Kompletne sprawdzenie systemu plików odbywa się w tle podczas pracy systemu Proces odśmiecania. Przenoszenie aktualnych danych bliżej głowy Tablica zajętości segmentów Aby pracować z takim system plików potrzebna jest ogromna pamięć fizyczna !

Księgowanie metadanych (logfile) Normalny system plikow + plik dziennika Dziennik jest odczytywany tylko po krachu Unikamy wielu problemów z LFS Semantyka zmiany danych Uaktualnij cache, zaznacz bufor jako ‘brudny’, stwórz wpis dziennika, zapisz log, potem kiedyś zapisz faktyczne dane. Grupowanie logów (mkdir) = szybkość Ograniczenia w wielkości pliku dziennika Odśmiecanie, lub częste in-place zapisy

Księgowanie metadanych Spójność pliku dziennika Wiele zmian na raz (na jednym obiekcie) – łatwo stracić spójność Gwarancja kolejności - zapis in-place musi być później niż logowanie Gwarancja transakcji – grupowanie logów + zabronienie odczytu danych nie zalogowanych, działa dla logów redo-undo Odtwarzanie Wykonaj polecenia z logu Jak znaleźć koniec i początek logu -> każdy wpis posiada głowę i ogon logu. Czas zależny od wielkości pliku dziennika Brak odtwarzania danych ! (demon update)

Sposób na zepsucie P1 P2 Nie można przywrócić A ani odtworzyć B Modyfikuj A i B (operacje zależne) Zapis A do logu i na dysk Modyfikacja obiektu A Zapis B do logu i na dysk Czytaj A Nie można przywrócić A ani odtworzyć B Modyfikuj B Zapisz B do logu Zapisz A do logu Zapisz B na dysk Zapisz A na dysk

`Watchdog` i portal Watchdog to demon w trybie użytkownika Implementacja wybranych wywołań systemowych na i-węźle. Jeśli i-węzeł jest katalogiem, to także na całym poddrzewie Korzysta z funkcji systemowych, ale to jego wyniki są zwracane do użytkownika ACL, kompresja, biff, [dir|file]view, date, logowanie Kanały komunikatów jako interfejs Portal, to watchdog, tyle że na stałe w systemie. Wirtualny system plików (tak jak /proc) Np. cd /p/tcp/rainbow/ftp

SGI XFS 64bity -> 9,223,372,036,854,775,807 bajtów Struktura Dodatkowy interfejs 32bitowy dla zgodności 32bitowe aplikacje mogą zapisywać powyżej 2GB NFS3 ma 64bitowy protokół Struktura Grupy alokacji (podwoluminy = zrównoleglenie), `extends` Metadane są w B-drzewie, a nie w bitmapie Rozmiar i-węzła jest ustalany przy mkfsie, ale ich ilość i położenie na dysku nie. `Spokrewnione’ dane trzymane są blisko siebie

SGI XFS (cd) Możliwości Cechy XFS B. duże pliki obsługiwane są nie wolniej (lista extendów) Średnie i małe, ekstremalnie szybko (b-drzewo) Cechy XFS Zmienny rozmiar extendów (512B ~ 1GB) Pliki `sparse` Mapowanie do pamięci Opóźniona alokacja bloków dyskowych (extends) Ogromne katalogi (miliony wpisów, a wciąż szybkie) Definiowalne atrybuty (np. język w jakim jest dokument) Rekonfiguracja, backup/restore on-line

Księgowanie (zintegrowane) SGI XFS (cd) Księgowanie (zintegrowane) Większość operacji na logu asynchroniczna W czasie pracy log nie jest odczytywany Transakcyjność poprzez atomowość operacji Odtwarzanie informacji zależy od użycia systemu w momencie krachu, a nie od rozmiaru partycji. xlv volume manager Łączenie woluminów w dyski, dzielenie (striping), dublowanie (plexing) Zrównoleglanie operacji

Gwarantowany transfer na XFSie Możliwość rezerwowania sobie minimalnych wartości zasobu (transferu danych) Twarde i miękkie rezerwacje Ograniczenia Sprzęt: twarde tylko na SCSI Utrata niektórych właściwości systemu plików Ustalonej wielkości extendy (ok. 1MB) Brak buforowania Brak implementacji B-Drzewa Dodatkowy demon Wykorzystywane w transmisjach on-line, i do programów działających real-time. Programiści nie muszą się martwić o dane

XFS jest przenoszony na Linuxa Dobra wiadomość XFS jest przenoszony na Linuxa http://oss.sgi.com/projects/sgilinux http://oss.sgi.com/projects/sgilinux11ux

RaiserFS – przyspieszanie Linuxa Wyrównywanie bloków Konwersje do całych bloków Ogon może być w dwóch blokach Separacja ogona od pliku Niebuforowane operacje mogą powodować duże wahania drzewa Dla małych plików poważne przyspieszenie Preserve list (księgowanie?) Metadane nie zastępują starych, są zapisywane blisko nich Czasem istnieje potrzeba serializacji zapisów do dysku

RaiserFS – moc w małych plikach Sumowanie małych obiektów w systemie plików Zwolnienie programistów od obowiązku zajmowania się problemem małych plików (np. bazy danych) Mniej kodu, wydajniejszy, nie trzeba tworzyć nowych warstw oprogramowania, itd.... ~80% to małe pliki ! – więc warto

RaiserFS – drzewo zrównoważone Pomysł z baz danych Na początku miał być hashing Typy węzłów Wewnętrzne wskaźniki do poddrzew + najmniejsze klucze w poddrzewie Niesformatowane (bez kluczy), są na samym dole drzewa Sformatowane zawierają klucze i wartości: Pośrednie – wskaźniki do niesformatowanych (dane plików) Bezpośrednie – ogony plików Katalogi – klucze wpisów + nazwy stat data (być może będzie razem z danymi o katalogu)

RaiserFS – wygląd drzewa Root Węzły wewnętrzne Węzły sformatowane są na przedostatnim poziomie Węzły niesformatowane to bloki dyskowe Definicje węzłów

RaiserFS – optymalizacje Dobór kluczy (od tego sporo zależy) <locality, object_id, offset, uniqueness> Pliki z katalogu są trzymane razem Podkatalogi również Rownoważenie Minimalizacja ilości węzłów Minimalizacja użytych w operacji węzłów Minimalizacja ilości węzłów które wypadną z cachu Przy przenoszeniu danych, maksymalizacja ilości danych Całość operacji buforowana, stare wartości na `preserve list’ Testy

Odniesienia Uresh Vahalia – „Unix Internals” http://devlinux.com/projects/reiserfs http://oss.sgi.com/projects/xfs http://oss.sgi.com/projects/xfs/papers/xfs_white/xfs_white_paper.html http://www.sgi.com/Technology/xfs-whitepaper.html http://www-4.ibm.com/software/developer/library/jfs.html