Nowoczesne systemy plikw PORWNANIE Wymagania stawiane systemom plikw

Nowoczesne systemy plików PORÓWNANIE

Wymagania stawiane systemom plików Bezpieczeństwo danych n Szybkość działania n Możliwość rozszerzania o dodatkowe funkcje n

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

Historia Ext 3 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 (04. 1992) likwiduje wady Miniksa, ale też ma wady (fragmentacja) ► Xia. FS - minimalistyczny następca ext ► ext 2 – maksymalistyczny następca ext ► Zwycięstwo funkcjonalnego ext 2 ► ext 3 (11. 2001) – dziennikowy następca ext 2 ►

Historia NTFS Systemy plików FAT (File Allocation Table) ► FAT 12 (dyskietki) ► FAT 16 (MS-DOS, Windows przed 95 OSR 2) ► FAT 32 (Windows 95 OSR 2, 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 ►

Ograniczenia NTFS ext 3 Nazwa pliku 255 znaków Znaki w nazwie pliku Unicode 16 EB 16 GB do 2 TB 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 512 B-64 k. B 1 k. B-4 k. B System plików Wielkość pliku Wielkość woluminu Blok/klaster

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

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

Fizyczna Struktura ext 3 n n Dysk podzielony na grupy Metadane na początku każdego bloku

NTFS n n n Wszystko jest plikiem – MFT, Boot, itd. Master. File. Table 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.

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 16 KB.

Metapliki w NTFS 0. 1. 2. 3. 4. 5. 6. Master File Table Mirror Log. File (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) 7. 8. 9. 10. 11. 12. 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

Atrybuty plików w NTFS 1. Standard_Information n Zawiera standardowe informacje takie jak czas stworzenia, ostatniej modyfikacji, ostatniego dostępu, prawa dostępu itd. n (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) 2. Attribute_List n 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. n 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ą.

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

Atrybuty plików w NTFS c. d. 6. Volume_Name i Volume_Information n 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) 7. Data n 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ść. n 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.

Atrybuty plików w NTFS c. d. 8. Index_Root, Index_Allocation, Bitmap n Te atrybuty służą do implementacji B+-drzew. Bitmapa jest mapą zajętości dostępnych indeksów. 9. Reparse_Point n 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. n Reparse_Point wyklucza się z Extentended Attributes – plik może mieć albo jedno, albo drugie

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

Metadane w NTFS i ext 3 NTFS n n n Około 16 KB 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 (512 B – 4 KB) Wielkość metadanych zależy od wykorzystania dysku. ext 3 n n n 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. 128 B Bloki wielkości od 1 do 4 KB Stała ilość miejsca przeznaczona na metadane

Wzbogacanie systemu plików n ACL (Access Control Lists) n n 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 n Spowolnienie działania operacji plikowych. n

Atrybuty u u u 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:

Atrybut Data (nierezydentny)

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

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

Nagłówek atrybutu nierezydentnego u 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:

Optymalizacje dostępu do zawartości katalogu - NTFS u u u 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 VCNach B+-drzewo szybciej rośnie na szerokość niż na wysokość

Optymalizacje dostępu do zawartości katalogu – ext 3 - Długo tylko proste listy łączone (do ext 2): 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 u Decyzja: H-drzewa (Hash Trees) u u -

H-drzewa w ext 3 u u u W wersjach rozwojowych ext 2, na dobre w ext 3 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 50 -100 razy szybsze!

Kompresja plików ext 3: u Teoretycznie możliwa (pole i_flags w i-węźle) u Dostępna w łatach zawartych w pakiecie e 2 compr (1997) w Ext 2 u Brak wsparcia dla kompresji w ext 3 (nawet dla tych łatek) NTFS: u Kompresja rzadkich danych u Kompresja gęstych danych u Rzadkie pliki

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

Rzadkie dane cz. 2 u 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)

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

Gęste dane cz. 2 u 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

Rzadkie pliki u u u 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)

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.

Linki • Ogólnie są 2 typy: – Twarde (hardlinks) • • • 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

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

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

Sposoby zapisu danych na dysk n ostrożne – system stara się n leniwe – system wykonuje operacje wykonywać operacje w kolejności gwarantującej maksymalną spójność w kolejności optymalizującej ruchy głowicy dysku

Przyczyny powstawania błędów n fizyczne n n n wynikające z konstrukcji dysku, bad blocks wynikające z działania czynników zewnętrznych logiczne n n n 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

Rodzaje błędów logicznych n n n 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

Atomowość operacji n n n z czego składają się operacje po co nam atomowość operacji właściwe operacje na przykładzie usuwania pliku w systemie UNIX: n n n 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ć

Kronika n n n Czym jest kronika? Po co nam kronika? Zalety n n 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 n n niektóre operacje mogą zajmować więcej czasu większe skomplikowanie systemu plików

Rodzaje kronikowania n n rejestrowanie odtwarzające (redo logging) rejestrowanie odwołujące (undo logging)

Tryby kronikowania n n kronikowanie metadanych (write-back) kronikowanie wszelkich operacji (także danych) (journalling) zapisywanie do dziennika pełnych bloków (klastrów) n zapisywanie tylko zmian w danych n n tryb „uporządkowany” (ordered)

Typy kronikowania obsługiwane przez systemy plików metadane i metadane • NTFS ■ □ • ext 3 • Reser. FS ■ ■ ■ □ • Reiser 4 □ ■ • JFS ■ □ • XFS ■ □ • Win. FS ■ ■ tryb ordered ■

Czas odtwarzania dzienników przez systemy plików n n Podczas montowania systemu plików Podczas sprawdzania spójności systemu plików

Położenie dzienników n n n jako jeden z plików w systemie (ext 3, NTFS, w specjalnym wydzielonym obszarze (XFS) w dowolnym miejscu systemu plików (Reiser 4)

ext 3 n ext 3 = ext 2 + JBD

Co jeśli dziennik zawiedzie n n kontrola spójności systemu nic

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

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

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

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

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

Win. FS Czyli dokąd zmierzają systemy plików

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

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

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

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

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

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

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

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

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

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

Plik $Secure file u u 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

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

Działanie EFS u u u 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ć 3 DES-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

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

Szczegóły działania EFS (skrót) u u u EFS działa w trybie jądra, pracę zleca mu NTFS Do odszyfrowania FEK-a używa funkcji kryptograficznych z trybu użytkownika Sterownik KSec. DD 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

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

Dostęp do innych systemów plików spod Linuksa n n n 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

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

Pytania i odpowiedzi ? ! Brak!!

Bibliografia n n n n Wikipedia Microsoft Tech. Net “How NTFS Works” Linux-NTFS Project http: //www. easeus. com/resource „Windows Internals” Moshe Bar „Linux – systemy plików” William von Hagen „Systemy plików w Linuksie” Google

Dziękujemy za UWAGĘ!