Nowoczesne systemy plików

1. Nowoczesnesystemy plików Rafal@Wijata.com

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. 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 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ć Aani 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 • 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 • 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. 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. Dobra wiadomość • XFS jest przenoszony na Linuxa • http://oss.sgi.com/projects/sgilinux • http://oss.sgi.com/projects/sgilinux11ux

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” • 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