Nowoczesnesystemy 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.

4.4BSD – LFS

Przywracanie spójnościOdczyt 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łowyTablica 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 dziennikaDziennik jest odczytywany tylko po krachuUnikamy wielu problemów z LFS

Semantyka zmiany danychUaktualnij 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 dziennikaOdś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 zepsucieP1 P2

Modyfikacja obiektu A

Czytaj A

Modyfikuj B

Zapisz B do logu

Zapisz B na dyskZapisz A do logu

Zapisz A na dysk

Modyfikuj A i B (operacje zależne)

Zapis A do logu i na dysk

Zapis B do logu i na dysk

Nie można przywrócić Aani odtworzyć B

`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 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 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

SGI XFS (cd)

Księgowanie (zintegrowane)Większość operacji na logu asynchronicznaW czasie pracy log nie jest odczytywanyTransakcyjność poprzez atomowość operacjiOdtwarzanie 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

Dobra wiadomość

XFS jest przenoszony na Linuxahttp://oss.sgi.com/projects/sgilinuxhttp://oss.sgi.com/projects/sgilinux11ux

RaiserFS – przyspieszanie Linuxa

Wyrównywanie blokówKonwersje do całych blokówOgon może być w dwóch blokachSeparacja ogona od plikuNiebuforowane operacje mogą powodować duże

wahania drzewaDla małych plików poważne przyspieszenie

Preserve list (księgowanie?)Metadane nie zastępują starych, są zapisywane blisko

nichCzasem 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 drzewaRoot

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/xfshttp://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