Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Nowoczesne systemy plików

Podobne prezentacje


Prezentacja na temat: "Nowoczesne systemy plików"— Zapis prezentacji:

1 Nowoczesne systemy plików

2 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

3 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

4 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

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

6 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 !

7 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

8 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)

9 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

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

11 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

12 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

13 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

14 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

15 XFS jest przenoszony na Linuxa
Dobra wiadomość XFS jest przenoszony na Linuxa

16 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

17 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

18 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)

19 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

20 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

21 Odniesienia Uresh Vahalia – „Unix Internals”


Pobierz ppt "Nowoczesne systemy plików"

Podobne prezentacje


Reklamy Google