Nowoczesne systemy plików
description
Transcript of Nowoczesne systemy plików
Nowoczesnesystemy plików
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