Nowoczesne systemy plików

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

1 Nowoczesne systemy plików
PORÓWNANIE

2 Wymagania stawiane systemom plików
Bezpieczeństwo danych Szybkość działania Możliwość rozszerzania o dodatkowe funkcje To są 3 główne cechy, których wymagamy od dzisiejszych systemów plików, z czego najważniejszą cechą jest oczywiście bezpieczeństwo. Nie bez znaczenia dla użytkownika jest również szybkość działania systemu plików, gdyż ma ona ogromnych wpływ na działanie całego systemu. Coraz częściej jednak przydają się również możliwości rozszerzania systemów plików o funkcje niebezpośrednio związane tylko z przechowywaniem danych, ale udostępniające dodatkowe funkcje czy to kontroli dostępu, wzbogacania danych o kolejne atrybuty, wskazywanie związku między plikami, czy też kolejne ułatwienia dla użytkowników. W związku z tym systemy plików stają się coraz bardziej skomplikowane, a część z nich ukierunkowuje się na jedną z wyżej wymienionych cech, lub na określone konkretne zastosowania.

3 Wstęp W trakcie prezentacji skupimy się na porównaniu dwóch najpopularniejszych obecnie systemów plików: ext3 NTFS Na wstępie omówimy ich historię.

4 Historia Ext3 System plików w systemie operacyjnym Minix i jego niedoskonałości (max rozmiar woluminu 64 MB) VFS (Virtual File System) System plików ext ( ) likwiduje wady Miniksa, ale też ma wady (fragmentacja) XiaFS - minimalistyczny następca ext ext2 – maksymalistyczny następca ext Zwycięstwo funkcjonalnego ext2 ext3 ( ) – dziennikowy następca ext2

5 Historia NTFS Systemy plików FAT (File Allocation Table)
FAT 12 (dyskietki) FAT 16 (MS-DOS, Windows przed 95 OSR2) FAT 32 (Windows 95 OSR2, Windows 98, Windows ME) Budowa tablicy alokacji plików bardzo prosta NTFS w 1995 (Windows 2000, Windows XP, Windows 2003 Server) NTFS – znacznie polepszony system plików, MFT (Master File Table) zamiast FAT

6 Zależy od liczby i-węzłów
Ograniczenia System plików NTFS ext3 Nazwa pliku 255 znaków Znaki w nazwie pliku Unicode Wielkość pliku 16 EB 16 GB do 2 TB Wielkość woluminu 16 EB (256 TB) 2 TB do 32 TB Liczba plików 232-1 Zależy od liczby i-węzłów Poziomy zagnieżdżenia Nieograniczona Blok/klaster 512 B-64 kB 1 kB-4 kB

7 Klastry w NTFS Rozmiar woluminu Rozmiar klastra 512 MB i mniej 512 B
513 MB-1024 MB 1 kB 1025 MB-2048 MB 2 kB Więcej niż 2048 MB 4 kB

8 Fizyczna Struktura NTFS
Wolumin stawnowi (mniej więcej) całość. Metapliki gdziekolwiek na woluminie MFT zajmuje początek dysku

9 Fizyczna Struktura ext3
Dysk podzielony na grupy Metadane na początku każdego bloku

10 NTFS Wszystko jest plikiem – MFT, Boot, itd.
MasterFileTable jest relacyjną bazą danych, w której wierszami są pliki, a kolumnami atrybuty. Wszystko w pliku jest atrybutem – łącznie z zawartością. Atrybuty to strumienie danych (ciągi bajtów). WSZYSTKIE pliki mają swoje rekordy w MFT – tak MFT też ma rekord w MFT.

11 Master File Table MFT musi gdzieś przechowywać wszystkie informacje o systemie plików. Jak wszystko inne, są one w plikach. Te pliki zajmują pierwsze 16 rekordów MFT (ostatnie 4 z nich są wolne, ale zarezerwowane na przyszłość) i około 16KB.

12 Metapliki w NTFS Master File Table Mirror LogFile (dziennik)
Volume (informacje o woluminie) Attribute definitions (lista wszystkich dopuszczalnych atrybutów plików) Root file name index (katalog główny) Cluster bitmap (bitmapa zajętości klastrów) Boot sector (zawiera BIOS parameter block czyli sprzętowe informacje o woluminie i ew. kod startujący system operacyjny) Bad cluster file (plik zawierający wszystkie uszkodzone klastry – jeśli są zajęte przez jakiś plik to nikt inny nie będzie ich używał) Security file Upcase table (tablica do tłumaczenia znaków na ich wielkie odpowiedniki) NTFS extension file 12-15 są wolne

13 Atrybuty plików w NTFS Standard_Information Attribute_List
Zawiera standardowe informacje takie jak czas stworzenia, ostatniej modyfikacji, ostatniego dostępu, prawa dostępu itd. (Stemple czasowe na dysku są uaktualniane co godzinę – aktualne informacje zawsze są dostępne w pamięci i są zrzucane na dysk tylko wtedy jeśli zamkniemy wszystkie deskryptory pliku, albo czas ostatniego dostępu w pamięci jest o godzinę późniejszy niż zapisany na dysku) Attribute_List Czasami zdarza się, że wszystkie rezydentne atrybuty pliku nie mieszczą się w jednym rekordzie MTF. W takim wypadku plikowi przydzielane są dodaktowe rekordy, a attribute_list jest listą wskaźników do nich. Rzadko widywane, gdyż większość danych może być przechowywana poza MFT. Przykładem kiedy jest to potrzebne jest plik z dużą liczbą twardych dowiązań – kiedy wszystkie nazwy się nie mieszczą.

14 Atrybuty plików w NTFS c.d.
File_Name Zawiera dwie nazwy – długą (do 255 znaków) i krótką (do 8 znaków), oraz wielkość pliku. Długa nazwa składa się z wielkich liter, krótka już nie koniecznie Wielkość pliku jest wielkością podstawowego (nienazwanego) strumienia danych Object_ID Zawiera unikalne numery pliku: obecny, urodzenia i wolumin na której powstał plik. Security_Descriptor Tutaj są przechowywane uprawnienia dostępu do pliku dla własciciela, grupy i reszy świata. Mówi też które akcje mają być logowane.

15 Atrybuty plików w NTFS c.d.
Volume_Name i Volume_Information Tylko pliki $volume posiadają te atrybuty – pierwszy zawiera nazwę, a drugi m.in. bit „Dirty”, mówiący czy przy ponownym uruchomieniu należy wykonać chkdsk /f (spróbować naprawić dysk) Data Atrybut będący zawartością pliku. Każdy plik musi mieć jeden nienazwany atrybut data będący jego standardową zawartością. Może też zawierać dowolnie dużo nazwanych atrybutów – każdy może mieć zupełnie inną zawartość. Jako, że wielkością pliku jest wielkość jego nienazwanej zawartości może istnieć plik, którego wielkość system plików podaje jako 0, a na dysku zajmuje dowolnie dużo miejsca.

16 Atrybuty plików w NTFS c.d.
Index_Root, Index_Allocation, Bitmap Te atrybuty służą do implementacji B+-drzew. Bitmapa jest mapą zajętości dostępnych indeksów. Reparse_Point Robi to co sugeruje nazwa – parsuje odwołanie od nowa, korzystając z danych zapisanych w tym atrybucie. Służy do tworzenia dowiązań symbolicznych, czy montowania zewnętrznych plików/katalogów/dysków. Reparse_Point wyklucza się z Extentended Attributes – plik może mieć albo jedno, albo drugie

17 Atrybuty plików w NTFS c.d.
EA i EA_Information (Extended Attribute) Służą do przechowywania dodatkowych atrybutów z HPFS (High Performance File System) – używane np. w OS/2 Logged_Utility_Stream Absolutnie cokolwiek co autor uzna za stosowne. Ma ograniczenie wielkości do 64kB. Wszystkie operacje na nim są zapisywane w dzienniku.

18 Metadane w NTFS i ext3 NTFS ext3
Około 16KB zarezerwowanych na metapliki. Bardzo mała redundancja danych – 4 rekordy z MFT w środku dysku. MFT zmiennej wielkości. Wpis w MFT od 1 do 4 KB Klastry małe (512B – 4KB) Wielkość metadanych zależy od wykorzystania dysku. ext3 Pierwsze kilka bloków (co najmniej 5) w każdej grupie zarezerwowane na metadane. Bardzo duża redundancja danych (kopie w każdej grupie). Stała wielkość tablicy i-nodów. I-węzeł wielkości ok. 128B Bloki wielkości od 1 do 4KB Stała ilość miejsca przeznaczona na metadane

19 Wzbogacanie systemu plików
ACL (Access Control Lists) Możliwość przydzielania uprawnień poszczególnym użytkownikom / grupom użytkowników Sumy kontrolne plików Lepsza kontrola uszkodzeń plików Możliwość stwierdzenia nieuprawnionego dostępu Spowolnienie działania operacji plikowych.

20 Atrybuty Rezydentne – zawarte w 1-kilobajtowym wpisie w MFT, np. Standard Information czy Filename Nierezydentne – przechowywane na dysku, nie mieszczą się we wpisie do MFT, alokowane w ekstentach (np. czasami Data czy Index root) Typ atrybutu umieszczony w jego nagłówku:

21 Atrybut Data (nierezydentny)

22 Atrybuty indeksowe (nierezydentne)
Atrybuty: Index root, Index allocation, Bitmap Ekstenty w tym przypadku nazywamy buforami indeksowymi

23 Numery klastrów LCN (Logical Cluster Numbers) – numery fizycznych klastrów dyskowych VCN (Virtual Cluster Numbers) – numery przypisywane kolejnym klastrom, przyporządkowywanym danemu plikowi lub katalogowi

24 Nagłówek atrybutu nierezydentnego
W ramach nagłówka atrybutu nierezydentnego są pamiętane kolejne ekstenty, a dla każdego numer wirtualny i logiczny pierwszego klastra i liczba klastrów w ekstencie:

25 Optymalizacje dostępu do zawartości katalogu - NTFS
Katalog jako B+-drzewo plików i podkatalogów (nazwy, wielkości, stemple czasowe i położenia w MFT) Index root to posortowana lista albo B+-drzewo, węzły w buforach indeksowych Index allocation to mapowanie między numerami VCN a LCN buforów indeksowych Bitmap to mapa zajętości buforów indeksowych po ich VCN-ach B+-drzewo szybciej rośnie na szerokość niż na wysokość

26 Optymalizacje dostępu do zawartości katalogu – ext3
Długo tylko proste listy łączone (do ext2): dobre dzięki strukturom dcache złe dla cache przeglądarek i niektórych systemów pocztowych Rozważania na temat użycia B-drzew: trudna i długa implementacja mała odporność na zniszczenie węzłów wewnętrznych Decyzja: H-drzewa (Hash Trees)

27 H-drzewa w ext3 W wersjach rozwojowych ext2, na dobre w ext3
32-bitowe hasze jako klucze Węzły wewnętrzne (bloki indeksowe) zajmują tylko 8 bajtów Stała głębokość (1 lub 2) Wsteczna kompatybilność (+odporność na zniszczenia): bloki-liście identyczne z blokami starego typu bloki indeksowe widziane jako usunięte wpisy katalogowe Dla dużych katalogów nawet razy szybsze!

28 Kompresja plików ext3: Teoretycznie możliwa (pole i_flags w i-węźle)
Dostępna w łatach zawartych w pakiecie e2compr (1997) w Ext2 Brak wsparcia dla kompresji w ext3 (nawet dla tych łatek) NTFS: Kompresja rzadkich danych Kompresja gęstych danych Rzadkie pliki

29 Rzadkie dane cz. 1 Rzadkie dane – znaczną część stanowią zera (np. rzadka macierz) NTFS w ogóle nie pamięta zawartości zerowych ekstentów:

30 Rzadkie dane cz. 2 W MFT nieistniejące ekstenty nie są w ogóle zapisane (o ich istnieniu świadczy tylko nieciągłość w numerach VCN istniejących ekstentów)

31 Gęste dane cz. 1 Plik dzielony na jednostki kompresyjne (16 klastrów)
Kompresujemy tylko te jednostki, które wskutek tego zmniejszają się co najmniej o 1 klaster:

32 Gęste dane cz. 2 NTFS wie, które jednostki są skompresowane (zna liczności) Optymalizacje: Kompresja i zapis na dysk zmienionych danych wykonywane są leniwie Odczyt z wyprzedzeniem dzięki próbom alokacji kolejnych fizycznie ekstentów 16 wybrana jako „trade-off” między pamięcią a czasem działania

33 Rzadkie pliki Podobne do skompresowanych metodą kompresji rzadkich danych Proces wskazuje, które fragmenty pliku uznaje za puste Przydatne w aplikacjach typu klient-serwer z buforem (unikamy nieskończonego wzrostu bufora)

34 Distributed Link Tracking
W systemie NTFS, tworząc twardy link do pliku zapamiętujemy Object_Identifier pliku docelowego. Ten identyfikator jest unikalny dla systemu i nie zmienia się przez cały czas życia pliku. Dzięki temu po zmianie nazwy, przeniesieniu pliku docelowego w inne miejsce itp. link cały czas jest poprawny.

35 Linki Ogólnie są 2 typy: Twarde (hardlinks) Miękkie (junctions)
Trzymane są wskaźniki do tego samego pliku. Plik jest usuwany gdy wszystkie wskaźniki znikną Windows nie obsługuje hardlinka dla katalogów. Miękkie (junctions) Trzymana jest ścieżka do pliku Gdy plik zostaje skasowany ścieżki są błędne Windows obsługuje miękkie linki tylko do systemu lokalnego

36 Quota – kontyngenty dyskowe
Umożliwiają kontrolę miejsca zajmowanego przez użytkownika Liczą całe pliki (czyli pliki rzadkie mają pełną wielkość) Można kontrolować poszczególnych użytkowników na różnych woluminach

37 Quota – kontyngenty dyskowe
Dwie tabele umożliwiające szybkie sprawdzanie czy użytkownik nie przekracza limitów W pierwszej tabeli można szybko znaleźć do kogo należy dany SID A w drugiej, ile ta osoba ma jeszcze miejsca wolnego

38 Sposoby zapisu danych na dysk
ostrożne – system stara się wykonywać operacje w kolejności gwarantującej maksymalną spójność leniwe – system wykonuje operacje w kolejności optymalizującej ruchy głowicy dysku Systemy plików otrzymując żądania wykonania operacji, poszczególne ich elementy może szeregować w różny sposób. Pierwszy z nich ostrożny polega na tym, że system w każdym momencie dba by dane znajdowały się w możliwie spójnej formie. To znaczy nie stara się obronić przed występowaniem niespójności, natomiast stara się tak uszeregować żądania zapisu, aby nawet w najgorszym wypadku niespójności te były możliwie przewidywalne, oraz nie były one krytyczne, tak aby system mógł je naprawić w dogodnym momencie, nie było zaś konieczne dogłębne sprawdzanie podczas startu. Np. podczas alokacji miejsca dla plików najpierw ustawiane są odpowiednie bity w bitmapie, a potem przydzielane jest miejsce na plik, w ten sposób jeśli awaria nastąpi po pierwszej operacji system najwyżej straci dostęp do pewnych bloków, ale istniejące już dane nie będą uszkodzone. Implikuje to także, że wszystkie operacje są wykonywane w kolejności, gdyż przeplatanie operacji może prowadzić do powstawania niespójności. Ostrożne zapisywanie poświęca szybkość operacji dla względnego bezpieczeństwa, drugie podejście jest zupełnie inne. Zapisywanie leniwe zapisuje w cache’u operacje, a następnie wykonuje ję w zoptymalizowanej kolejności. Daje to wzrost wydajności z dwóch powodów, po I może zoptymalizować kolejność żądań, tak aby zminimalizować niepotrzebne ruchy głowicy dysku, po drugie może zaoszczędzić wiele operacji, gdyż dane zapisane w buforach mogą się zmienić wielokrotnie zanim zostaną odesłane na dysk. Czas obsługi aplikacji jest też generalnie krótszy, gdyż możemy zwrócić sterowanie do programu, zanim jeszcze operacja zostanie zakończona. Jednak ma on bardzo poważną wadę, gdyż jeśli nastąpi awaria systemu zanim wszystkie operacje zostaną zakończone system może znajdować się w bardzo niespójnym stanie.

39 Przyczyny powstawania błędów
fizyczne wynikające z konstrukcji dysku, bad blocks wynikające z działania czynników zewnętrznych logiczne wynikające z błędnego działania systemu wynikające z błędów w implementacji systemu plików wynikające z przerwania operacji na systemie plików Głównym zadaniem systemów plików jest przechowywanie danych, jak więc się dzieje, że niekiedy dane te znikają, lub nie są dokładnie takie, jak je zapisywaliśmy. Systemy typu WORN (Write-Once-Read-Never) nigdy nie zdobyły zbyt dużej popularności. Po co w ogóle rozpatrujemy bezpieczeństwo systemu plików – ponieważ większość danych zapisujemy na dyskach, które mają pewne ograniczenia, gdyby istniała tania, szybka, trwała, niezawodna i o dużej pojemności pamięć operacyjna dyski twarde nie byłyby już wówczas potrzebne. Powody tego mogą być różne, poczynając od fizycznych awarii napędów, polegających czy to na wadliwym działaniu samego dysku twardego (wad materiałów, z których został wykonany, zużycia powłoki odpowiedzialnej za przechowywanie danych), czy też zniszczeń fizycznych spowodowanych przez czynniki zewnętrzne (woda, ogień, walec drogowy…). Jednak na tego typu awarie systemy plików nie są w stanie wiele poradzić, mogą one wspierać różne metody robienia kopii bezpieczeństwa, jednak jako że przyczyna powstania problemów jest fizyczna fizyczne rozwiązania sprawdzają się najlepiej. I mamy tutaj wszelkiego rodzaje macierze dysków twardych RAID (poza typem 0 – który wręcz obniża bezpieczeństwo) oraz replikowanie plików na zewnętrznych nośnikach. Logiczne błędy na dysku, czy też mówiąc inaczej – niespójności metadanych systemu plików z właściwą zawartością dysku również powstają najczęściej w wyniku działania czynników fizycznych, których najczęstszym przejawem jest awaria zasilania (przed którą możemy również chronić się przy pomocy zasilaczy awaryjnych), lub błędne działanie programów. Myślę, że każdemu z nas przytrafiła się utrata danych w wyniku awarii zasilania, czy to z powodu nie zapisania ostatnio wprowadzonych zmian, czy też dlatego że zapisanie tych zmian nie odbyło się jeszcze do końca na dysku.

40 Rodzaje błędów logicznych
skrzyżowane pliki zagubione klastry (bloki) nieprawidłowe wartości liczników odwołań pliki do których nie ma dostępu błędne rozmiary plików wszelkie inne niespójności metadanych W systemie plików mogą wystąpić bardzo różne błędy logiczne, zwane często niespójnościami. Najpopularniejszymi z nich mogę być skrzyżowane pliki, sytuacja ta występuje wówczas, gdy dwie (lub więcej) struktury opisujące pliki, twierdzą że dany klaster (blok) należą do danego pliku. Kolejnym bardzo powszechnie występującym błędem logicznym są zagubione klastry (bloki), ma to miejsce wówczas, gdy pomimo, że w odpowiednich bitmapach dane miejsce jest uznane za zajęte, jednak żadna struktura opisująca plik nie odwołuje się do tego miejsca. Problem mogą stanowić także nieprawidłowe wartości licznika odwołań, występujące gdy wartość licznika jest różna od rzeczywistej liczby odwołań do danego pliku. Błędne rozmiary plików nie wymagają chyba dodatkowego komentarza. Nie są to jednak wszystkie niespójności, które mogą wystąpić w systemie, gdyż jest ich wiele więcej, część z nich może zależeć od konkretnego systemu plików i reprezentacji metadanych przez niego przyjętych. Mogą to być wszelkiego rodzaju błędne atrybuty, błędne czasy dostępu

41 Atomowość operacji z czego składają się operacje
po co nam atomowość operacji właściwe operacje na przykładzie usuwania pliku w systemie UNIX: usunięcie wpisu odnośnie pliku w katalogu ustawienie i-węzła pliku jako wolnego w bitmapie. co złego może się wydarzyć Wydawać by się mogło z punktu widzenia użytkownika że wszystkie operacje na dysku powinny być atomowe, jednak tak nie jest, jesteśmy w stanie co najwyżej zapewnić atomowość operacji zapisu pojedynczego bloku na dysk. Zatem wiele operacji, które są podstawowymi operacjami dla użytkownika najczęściej składa się z wielu operacji na systemie plików i jego strukturach. Ważne jest zatem aby operacje te były atomowe – wykonały się albo wszystkie, albo żadna, gdyż w ten sposób system plików będzie w stanie spójnym. Przyjrzyjmy się operacji usuwania pliku w systemie UNIX: najpierw następuje usunięcie wpisu w katalogu następnie ustawiany jest i-węzeł pliku jako wolny. Wydaje się to całkiem naturalnie, jednak co się stanie, jeśli pierwszy krok zdąży się wykonać przed awarią systemu, a drugi już nie zdąży – będziemy mieli do czynienia z osieroconym i-węzłem, a w związku z tym wyciek pamięci, który może wykryć żmudne przeglądanie całego dysku. Z drugiej strony jeśli druga operacja zdąży się wykonać, a pierwsza nie, wówczas, może się zdarzyć, że ten i-węzeł zostanie przydzielony do innego pliku, a wpis w katalogu zostanie.

42 Kronika Czym jest kronika? Po co nam kronika? Zalety Wady
większe bezpieczeństwo krótszy czas przeładowania systemu często zaawansowane algorytmy i struktury danych używane do obsługi plików Wady niektóre operacje mogą zajmować więcej czasu większe skomplikowanie systemu plików Kronika, zwana też dziennikiem, jest miejscem, gdzie system plików zapisuje przyszłe zmiany w stosunku do systemu plików, rejestrując je zanim jeszcze operacje powodujące te zmiany zostaną faktycznie wykonane. Kronika przydatna jest szczególnie podczas awarii komputera, gdyż poprzez analizę operacji zapisanych w kronice system operacyjny może starać się przywrócić właściwy stan poprzez odtworzenie lub wycofanie przerwanych operacji. Pomaga to w spełnieniu jednego z podstawowych obowiązków systemu operacyjnego, jakim jest zapewnienie, że system plików znajduję się w spójnym stanie, przed udostępnieniem go użytkownikowi. Kronika pozwala zachować abstrakcję atomowości operacji na systemie plików. Do głównych zalet kroniki, a właściwie systemów plików z kroniką można zaliczyć zwiększone bezpieczeństwo danych (które jest jednym z najważniejszych wymagań stawianych systemom plików). Pozwalają też skrócić czas przeładowania systemu po awarii – jeśli system nie został zamknięty poprawnie, wówczas czas potrzebny na sprawdzenie poprawności dysku może być znaczący szczególnie przy rozmiarach dysków spotykanych w dzisiejszych czasach. Spróbujmy sobie wyobrazić ile zajęłoby wykonanie pełnego sprawdzania dysku rozmiaru 500 GB, co mogłoby być przyczyną dalszego przestoju systemu po awarii. Do głównych wad systemu plików z kroniką można zaliczyć zwiększony czas wykonywania niektórych operacji, wiążący się z dodatkowym nakładem na prowadzenie dziennika, jednak często przez zastosowanie zaawansowanych algorytmów i struktur danych (które już zostały wspomniane) nie zawsze jest to na tyle znacząca różnica, ze należy się nią przejmować, czasami nawet systemy plików z kroniką okazują się wydajniejsze. Kolejnym problemem może być idący za tym większy stopień skomplikowania systemu plików i operacji na nich, co może prowadzić do błędów w imlementacjach.

43 Rodzaje kronikowania rejestrowanie odtwarzające (redo logging)
rejestrowanie odwołujące (undo logging) Istnieją dwa podstawowe rodzaje rejestrowania transakcyjnego. Rejestrowanie odtwarzające polega na rejestrowaniu zmian danych w dzienniku przed ich faktycznym utrwaleniem na dysku. W przypadku awarii systemu, po zatwierdzeniu transakcji w dzienniku, ale przed utrwaleniem związanych z nią zmian w systemie plików, zmiany utrwala się przez ich odtworzenie (ponowne wykonanie) po przywróceniu systemu na podstawie zawartości dziennika transakcji. Żadna z transakcji, które nie zostały zatwierdzone, nie może spowodować trwałych zmian w systemie plików. Rejestrowanie odwołujące polega na równoległym zapisywaniu transakcji w dzienniku i utrwalaniu związanych z nim zmian w systemie plików. Jeżeli system ulegnie awarii przed zatwierdzeniem transakcji, dziennik musi zawierać informację niezbędne do wycofania już utrwalonych zmian związanych z niezatwierdzonymi transakcjami. Tak więc w przypadku korzystania z rejestrowania odwołującego wpisy dziennika muszą zwierać zarówno zapis stanu danych czy metadanych przed wprowadzeniem zmian, jak również zapis samych zmian. Większość systemów plików z kroniką korzysta z rejestrowania odtwarzającego.

44 Tryby kronikowania kronikowanie metadanych (write-back)
kronikowanie wszelkich operacji (także danych) (journalling) zapisywanie do dziennika pełnych bloków (klastrów) zapisywanie tylko zmian w danych tryb „uporządkowany” (ordered) Możemy wymagać od systemu plików by w dzienniku zapisywał zmiany dokonywane tylko w odniesieniu do metadanych, jak również wszelkich zmian dotyczących zarówno danych i metadanych. Rejestrowanie wszelkich zmian jest w sposób oczywisty bezpieczniejsze, ale za to dużo wolniejsze niż rejestrowanie wyłącznie zmian metadanych systemu plików. Powolność ta jest rezultatem konieczności wykonywania dla każdej zatwierdzonej transakcji dwóch zbiorów operacji zapisu – pierwszy zbiór zapisywany jest do dziennika, drugi faktycznie utrwala zatwierdzone zmiany w systemie plików. Trzeci tryb rejestrowania daje możliwość pełnego wykorzystania bezpieczeństwa systemu plików z kroniką rejestrującego pełen zestaw danych, nie obarczony spadkiem wydajności operacji. Osiągnięto to dzięki wymuszeniu zapisu na dysk wszelkich danych związanych z transakcją jeszcze przed aktualizacją odpowiednich metadanych systemu plików. Sposób ten gwarantuje uaktualnianie danych przed zapisem na dysk rejestru zmian metadanych, dotyczących zatwierdzonej transakcji, dzięki czemu dane przechowywane w plikach są po ich odtworzeniu na podstawie dziennika zawsze spójne z metadanymi systemu plików. Aby w pełni zobaczyć różnicę miedzy zapisywaniem tylko operacji dotyczących metadanych a zapisywaniem wszystkich zmian, rozważmy przykład dopisywania danych na końcu pliku. W systemie UNIX mogłoby to wyglądać w sposób następujący: zwiększ rozmiar i-węzła zaalokuj miejsce na dodatkowe dane zapisz dodatkowa dane do pliku Jeśli zapisywaliśmy tylko metadane, nigdy nie będziemy mieli pewności po awarii, czy przed awarią został wykonany krok 3, gdyż informacja na jego temat nie znajdzie się w dzienniku, w związku z tym plik ten może zyskać śmietnik na końcu.

45 Typy kronikowania obsługiwane przez systemy plików
metadane dane i metadane tryb ordered NTFS ■ □ ext3 ReserFS Reiser4 JFS XFS WinFS Jak widać różne systemy plików obsługują różne tryby kronikowania. Część z nich udostępnia też dodatkowe właściwe dla siebie mechanizmy pozwalające usprawnić lub lepiej zabezpieczyć operacje na kronice. I tak np. Reiser4 wykorzystuję wędrujące logi (wandering logs), aby zapewnić atomowość operacji, nie będąc zmuszonym do dwukrotnego zapisu tych samych danych stosuję się zmianę położenia danych i dziennika – korzysta to z założenia że zapis bloku jest operacją atomową.

46 Czas odtwarzania dzienników przez systemy plików
Podczas montowania systemu plików Podczas sprawdzania spójności systemu plików Można się zastanawiać kiedy systemy plików wykonują analizę zapisu kroniki, w przypadku nieprawidłowego zamknięcia. Większość systemów (w tym NTFS, ext3, XFS, ReiserFS, Reiser4) wykonują tę operacje automatycznie podczas montowania, tak aby nie udostępniać użytkownikom potencjalnie niespójnego systemu plików, jednak w przypadku systemu plików JFS, zawartość kroniki odtwarzana jest dopiero podczas sprawdzania programem fsck.xfs (fsck = file system consistency check).

47 Położenie dzienników jako jeden z plików w systemie (ext3, NTFS,
w specjalnym wydzielonym obszarze (XFS) w dowolnym miejscu systemu plików (Reiser4) Systemy plików z kroniką mogą się w sposób znaczący różnić umiejscowieniem pliku z kroniką w systemie. Najprostszym rozwiązaniem jest umieszczeniem jej bezpośrednio w systemie plików – nie wymaga to implementacji żadnych specjalnych operacji, zachowuje zgodność z systemami bez kroniki. Rozwiązanie to ma jednak również wady, gdyż operacje na kronice nie są jakoś specjalnie optymalizowane, jednocześnie podobnie jak wszystkie pozostałe pliki na dysku kronika jest wówczas podatna na awarie systemu plików, która może spowodować niemożność jej odczytu. Kolejną metodą jest umieszczenie kroniki w specjalnie do tego celu wydzielonym obszarze partycji. Rozwiązanie to pozwala zoptymalizować dostęp do kroniki, jak również pozwala zapewnić jej większe bezpieczeństwo poprzez odseparowanie jej od systemu plików. Obie te metody w przypadku niektórych systemów plików pozwalają umieścić dziennik na innym urządzeniu, co może mieć pozytywny wpływ na wydajność operacji, które mogą wykonywać się jednocześnie, jednak może też narazić system na awarię jeśli awarii ulegnie dysk, na którym przechowywane są logi. System JFS – choć nie jest to jeszcze zaimplementowane w linuxie pozwala na współdzielenie pliku z kroniką przez kilak systemów plików. W systemie Reiser4 została zastosowana technika wynalezioną przez Dave Hitz’a – WAFL (Write Anywhere File Layout filesystem).

48 ext3 ext3 = ext2 + JBD W tym miejscu chciałbym wspomnieć jak powstał system ext3 i jego głównej różnicy w stosunku do ext2. Kuba wspominał już o pewnych różnicach. Najważniejszą różnicą jest wzbogacenie systemu ext3 o dziennik. Wspaniałą zaletą systemu ext3, jest to, że jako, że jest on zbudowany na podstawie dobrze przetestowanego systemu ext2, jest on z nim praktycznie w 100% zgodny. Ma to daleko idące konsekwencję – gdyż możemy używać do niego narzędzi zaprojektowanych dla systemu ext2, jak dump i restore, fsck.ext3 jest również dowiązaniem symbolicznym do fsck.ext2, sam proces konwersji między systemami jest również całkowicie odwracalny, gdyż z jednej strony poprawnie domontowany system ext3, może być bez najmniejszych problemów zamontowany jako system ext2, jednocześnie konwersja z systemu ext2 do ext3 sprowadza się do jednego polecenia tworzącego dziennik… Pierwsze co zrobiono przy tworzeniu systemu ext3, było skopiowanie kodu źródłowego ext2, i zmiana wszystkich wystąpień ext2 na ext3.

49 Co jeśli dziennik zawiedzie
kontrola spójności systemu nic Zdarzyć się oczywiście mogą przypadki, kiedy dziennik zawiedzie i czy to poprzez niespójności dziennika, czy niemożności przeprowadzenia zapisanych w nim operacji system znajduje się w stanie niespójnym. Na taką okoliczność większość systemów plików z kroniką udostępnia jednak programy służące do kontroli poprawności metadanych. Są też systemy plików, których programiści są święcie przekonani, że taka sytuacja zajść nie może, co pozwala wierzyć w niezawodność ich systemów ;).

50 Problemy związane z kroniką
Istnieją operacje które mogą sprawić problem systemom z kroniką, np.: usuwanie pliku otwartego przez pewien proces przeplot operacji usuwania pliku i tworzenia nowego Specjalne wymagania odnośnie poleceń ponawiania i wycofywania

51 Kronika na przykładzie NTFS
kopia systemów startowych cykliczny zapis rekordów

52 Rekordy w kronice (na przykładzie NTFS)
rekordy uaktualnień punkty kontrolne

53 Przywracanie spójności systemu przy pomocy kroniki (na przykładzie NTFS)
Faza analizy kroniki Faza ponawiania operacji Faza wycofywania operacji

54 Sposoby na zabezpieczanie danych
Zasilacze awaryjne Kopie bezpieczeństwa Macierze dysków twardych

55 Czyli dokąd zmierzają systemy plików
WinFS Czyli dokąd zmierzają systemy plików

56 Podstawowe wymagania systemu plików
Przechowywanie informacji Dostęp do danych na dysku Szybki dostęp do danych Wyszukiwanie potrzebnych danych

57 Cechy aktualnych systemów plików
Szybkość Dobre zarządzanie miejscem Małe straty miejsca na metadane ALE : Struktura hierarchiczna Utrudnione wyszukiwanie Brak możliwości tworzenia połączeń między plikami

58 Próby radzenia sobie z problemami
Systemy plików Systemy operacyjne Tworzenie linków Trzymanie dodatkowych informacji razem z plikami Indeksowanie częstych zapytań ALE TO ZA MAŁO

59 Nowe podejście Wykorzystanie silnika bazy danych
Pod spodem „zwykły” system plików

60 Zalety Możliwość dodawanie wielu cech do plików i szybkiego ich wyszukiwania Brak katalogów – czyli brak sztywnego rozmieszczania plików Łatwe szukanie i dodawanie nowych połączeń.

61 Wady Trzeba poczekać aż do 2007. Więcej miejsca zajmą metadane
Większy koszt niektórych operacji Trudności w dostępie z innych OS Trzeba poczekać aż do 2007.

62 Windows Future Storage
Bazuje na NTFS Wsparcie dla Win32 Api Nowy „engine” SQL-a (Yukon)

63 Walka z fragmentacją – ext3
ext3 – metoda zapobiegania: Zupełnie jak w ext2 Prealokacja bloków (przydzielanie w partiach po 8) Przydzielanie nowych bloków w pobliżu już istniejących, w tej samej grupie bloków, co i-węzeł pliku Metody świetnie się spisują, długo nie rozważano tematu defragmentacji W ext2 do defragmentacji jest e2defrag W ext3 się go nie da użyć (bez konwersji do ext2)

64 Walka z fragmentacją - NTFS
NTFS – metoda skutecznego leczenia: Zapobieganie ogranicza się do rezerwacji specjalnego obszaru na dysku dla MFT Dobre API dla defragmentatorów: FSCTL_GET_VOLUME_BITMAP, FSCTL_GET_RETRIEVAL_POINTERS, FSCTL_MOVE_FILE. Własne narzędzie - \Windows\System32\Defrag.exe Wadliwe w Windows 2000, lepsze w XP i 2003 Server

65 Zarządzanie uprawnieniami
NTFS: W początkowej wersji NTFS przechowywał deskryptor bezpieczeństwa w każdym pliku (duże wykorzystanie miejsca dyskowego w systemach wieloużytkownikowych) W aktualnej wersji plik $Secure file trzyma wszystkie deskryptory bezpieczeństwa, a pliki mają tylko ich unikalne w danym systemie numery ext3: Prawa dostępu przechowuje i-węzeł dyskowy w polu i_mode (małe wykorzystanie miejsca)

66 Plik $Secure file Dwa sposoby indeksowania: SDH i SII, dane w atrybucie SDS Nadawanie deskryptora plikowi – wykorzystujemy SDH Przyzwalanie na dostęp – wykorzystujemy SII (pliki przechowują w $STANDARD_INFORMATION numer systemowy deskryptora) Cache’owanie ostatnich 32 użytych deskryptorów przez NTFS

67 Szyfrowanie w NTFS Przezroczyste dla użytkownika
Wykorzystanie EFS (Encrypting File System), w Windowsie 2000 osobny sterownik, a od Windowsa XP sterownik zintegrowany ze sterownikiem NTFS Użycie: poziom aplikacji: funkcje EncryptFile i DecryptFile, a FileEncryptionStatus zwraca atrybuty zaszyfrowania Eksplorator Windows – menu „zaawansowane właściwości” pliku lub katalogu Linia komend – polecenie cipher

68 Działanie EFS Pliki szyfrowane symetrycznym kluczem FEK (File Encryption Key) W Windows 2000 i Windows XP używany do tego DESX, a w Windowsie XP z Service Pack 1 i 2003 – AES Można też wybrać 3DES-a Szyfrowanie i deszyfrowanie symetryczne jest szybkie Użytkownik ma swój klucz publiczny i prywatny RSA, którym szyfruje się FEK Szyfrowanie niesymetryczne jest wolne, ale używamy go tylko do szyfrowania FEK-a

69 Bezpieczeństwo kluczy RSA
Klucz prywatny w katalogu: Documents and settings\Dane aplikacji\Microsoft\Crypto\RSA Katalog ten zaszyfrowany jest za pomocą master key danego użytkownika (64-bajtowy klucz symetryczny) Master key w katalogu Documents and settings\Dane aplikacji\Microsoft\Protect Jest zaszyfrowany algorytmem 3DES z użyciem klucza, który jest częściowo oparty na haśle użytkownika

70 Szczegóły działania EFS (skrót)
EFS działa w trybie jądra, pracę zleca mu NTFS Do odszyfrowania FEK-a używa funkcji kryptograficznych z trybu użytkownika Sterownik KSecDD zleca pracę dla LSASS (Local Security Authority Subsystem) Komponent LSASS-a – Lsarv – wysłuchuje żądania i przekazuje do CSP (cryptographic service provider) Lsarv przekazuje wynik z powrotem do EFS

71 Interoperacyjność Obsługa systemów plików: kernel based API
driver based API mieszane kernel-driver based API userland based API

72 Dostęp do innych systemów plików spod Linuksa
obsługa większości systemu plików występuje jako moduły jądra w przypadku NTFS programy open source nie oferują pełnej funkcjonalności istnieją komercyjne implementacje obsługi NTFS spod Linuksa – Paragon NTFS

73 Dostęp do innych systemów plików spod Windowsa
Zwykle nie nastręcza problemów, ze względu na otwartą specyfikację tych systemów plików Wymaga zainstalowania pewnych dodatkowych aplikacji

74 Pytania i odpowiedzi ?! Brak!!

75 Bibliografia Wikipedia Microsoft TechNet “How NTFS Works”
Linux-NTFS Project „Windows Internals” Moshe Bar „Linux – systemy plików” William von Hagen „Systemy plików w Linuksie” Google

76 Dziękujemy za UWAGĘ!