Nowoczesne systemy plików

Systemy plików z rodziny ext wywodzą się od systemu plików z systemu operacyjnego Minix, który został zaprojektowany w celach dydaktycznych przez prof. Andrew Tanenbauma. Ze względu na swoje przeznaczenie ten system plików był wolny od większych usterek i porządnie napisany; niestety posiadał dwa podstawowe ograniczenia, które powodowały, że musiał on zostać zmieniony przed wcieleniem go do systemu Linux: maksymalna wielkość woluminu wynosiła 64 MB, a maksymalna długość nazwy pliku: 14 znaków. Zaprojektowano więc najpierw warstwę VFS (Virtual File System), dzięki której łatwo jest podpinać do Linuksa różne systemy plików (wirtualny system plików operuje takimi pojęciami, jak i-węzeł, superblok, plik czy obiekt typu dentry, ale abstrahuje od ich implementacji dyskowej, którą wystarczy wykonać, aby dołączyć nowy system plików do Linuksa). Następnie w kwietniu 1992 udostępniono system plików ext, który usuwał najpoważniejsze ograniczenia Miniksa: maksymalny rozmiar woluminu wynosił 2 GB, a maksymalna długość nazwy pliku - 255 znaków.

System ten także miał pewne mankamenty: nie obsługiwał odrębnych znaczników czasowych dostępu, modyfikacji i-węzła i modyfikacji danych. Ponadto do śledzenia wolnych bloków oraz i-węzłów w systemie plików używał powiązanych list, ale w miarę korzystania z systemu plików listy stawały się nieposortowane, a system plików ulegał fragmentacji, co zmniejszało jego ogólną wydajność.

Te powody doprowadziły do opracowania dwóch nowych systemów plików: XiaFS (który był generalnie oparty na systemie plików Miniksa i oferował tylko kilka ulepszeń - tzn. długie nazwy plików, większe partycje i odrębne czasy modyfikacji, utworzenia i dostępu) oraz Ext2FS (oparty na ExtFS, z wieloma ulepszeniami i możliwościami rozszerzeń). XiaFS był stabilniejszy od Ext2FS (ze względu na minimalistyczną architekturę), ale z czasem w tym drugim wyeliminowano usterki, dodano wiele nowych funkcjonalności i to on stał się podstawowym systemem plików Linuksa na wiele lat. Ext2FS oferuje wiele potężnych narzędzi, które czynią go łatwo zarządzalnym:

Następcą Ext2FS jest Ext3FS (listopad 2001), który oferuje kilka nowych funkcjonalności (dziennik, możliwość powiększania wielkości partycji bez konieczności odmontowywania jej i używanie H-drzew - Hash trees - do przechowywania plików w katalogach). ext2 i ext3 bardzo łatwo konwertować pomiędzy sobą, co wobec kilku wad Ext3FS (brak narzędzi defragmentacyjnych - e2defrag wymaga przekonwertowania ext3 do ext2, zerowanie wskaźników do bloków w i-węzłach usuniętych plików - utrudnia odzyskiwanie danych, brak wsparcia dla przezroczystej kompresji - dostępnej w nieoficjalnej łacie na ext2) powoduje, że ext3 jest obecnie częściej stosowanym systemem plików Linuksa niż np. konkurencyjny ReiserFS (generalnie szybszy, ale mniej stabilny i działający o wiele wolniej w pewnych, złośliwych scenariuszach)

Został przedstawiony w 1995 roku i jest następcą używanych w systemie MS-DOS i we wczesnych wersjach Windowsa systemów FAT (File Allocation Table). Aktualnie wspierane jeszcze w Windowsie systemy FAT to FAT 12 (domyślny format dla 5- i 3.5-calowych dyskietek), FAT 16 (Windows przed 95 OSR2) i FAT 32 (Windows 95 OSR2, 98 i Millenium Edition). System FAT, jak sama nazwa wskazuje, opiera się na tablicy alokacji plików, która jest jego główną i jedyną obok wskazania na boot sector (2 kopie w FAT 32) i katalog superużytkownika (tego drugiego nie ma w FAT 32) metadaną systemu plików. Dla każdego pliku pamiętany jest w niej jego pierwszy klaster (odpowiednik bloku w ext-ach), który wskazuje z kolei na kolejny klaster plików itd., co daje tak zwany łańcuch alokacji pliku. Klastry nienależące do żadnego pliku są oznaczane zerem, a ostatnie klastry pliku -specjalną wartością, równą 0xFFFF w FAT 16 i 0xFFF w FAT 32. Rozmiar tablicy alokacji plików jest rozpoznawany po liczbie w zapisie FAT X (X=12, 16 lub 32) i równy 2X (X to liczba bitów, w jakiej są pamiętane numery klastrów). Rozmiar klastra jest zmienny; w FAT 12 rozmiar klastra to od 512 B do 8 kB, tabela domyślnych rozmiarów dla FAT 16 to:

a dla FAT 32 to:

Na podstawie powyższych informacji łatwo liczymy, że maksymalny rozmiar woluminu w FAT 12 to 32 MB, w FAT 16 to 4 GB, a w FAT 32 to 8 TB (ten ostatni teoretycznie, bo obsługuje takie wielkości, ale sam potrafi stworzyć do 32 GB). Wpis katalogowy zajmuje w FAT-ach 32 B (pamięta nazwę w formacie MS-DOS 8.3 - krótką, wielkość, początkowy klaster i czasu ostatniego dostępu i modyfikacji), więc długie nazwy są obsługiwane tandetnie poprzez dodawanie sztucznych wpisów katalogowych, które pamiętają tylko ciąg dalszy nazwy. Kolejnym ograniczeniem jest maksymalna wielkość pliku do 4 GB. Ogólnie systemy FAT są dość stabilne, ale tandetnie napisane i pozbawione wielu istotnych funkcjonalności. Obowiązywały do Windowsa ME.

NTFS jest następcą FAT-a od Windowsów 2000, XP i 2003 Server. Elementem wspólnym jest idea trzymania listy wszystkich plików i folderów w jednym miejscu (NTFS utrzymuje MFT=Master File Table, która jest znacznie lepszą i bardziej wszechstronną wersją File Allocation Table). Przełamuje on wiele ograniczeń wielkościowych systemów FAT (o tym w dalszej części) i oferuje istotnie więcej funkcjonalności, jak: obsługa quoty, zaawansowana kompresja plików (przezroczysta dla użytkownika), szyfrowanie, dziennik (umożliwia odzyskiwanie danych, którego zupełnie brakowało w FAT-ach - tam dla bezpieczeństwa danych przechowywano drugą kopię tablicy alokacji, gdyż utrata tej tablicy jest równoważna z małą szansą na odzyskanie danych) i system dowiązań twardych i symbolicznych.

Na początek warto wspomnieć, że ext3 został zaprojektowany jako nakładka na ext2 w taki sposób, żeby pozostawić dane zapisywane na dysku niezmienione - co oznacza, że struktura fizyczna tych dwóch systemów plików jest taka sama.

Dysk ext2 jest podzielony na grupy, które składają się z bloków. Bloki mają wielkość od 1KB do 4KB, liczba bloków w grupie zależy od wielkości bloku - bitmapa zajętości bloków w jednej grupie musi zajmować jeden blok - czyli waha sie od 8192 do 16384. W każdej grupie pierwsze kilka bloków (co najmniej 5) jest zajętych przez metadane (dane o danych). W kolejności są to:

Jak widać na metadane przeznaczony jest zawsze taki sam obszar w stosunku do objętości całego dysku, a redundancja danych jest stosunkowo duża - kopia najważniejszych danych znajduje się w każdym bloku - a bloków może być dowolnie dużo.

Figure 3.1. Schemat struktury dysku w ext3

Dysk NTFS jest zorganizowany zupełnie inaczej - na początek nie istnieje coś takiego, jak jakieś dane w dziwnych miejscach na dysku - wszystko trzymane jest w plikach. Z powodu swoich korzeni - a konkretnie wywodzenia się z systemu plików FAT - wszystkie informacje o plikach są trzymane w tablicy. Wcześniej nazywała się ona File Allocation Table, teraz nazywa się Master File Table (MFT). Co więcej Microsoft chwali się, że MFT już nie jest tablicą, a relacyjną bazą danych - ile w tym prawdy nie da się niestety sprawdzić.

Warto uświadomić sobie jeden fakt - wszystko jest plikiem, co znaczy, że MFT też. Informacje o wszystkich plikach znajdują się w MFT - czyli MFT trzyma też informacje o MFT. MFT znajduje się na początku dysku. Żeby zapobiegać fragmentacji, system plików rezerwuje pewną część dysku - domyślnie 12,5%, ale możliwe jest zwiększenie tego obszaru nawet do 50%. Nie jest tak, że ten obszar jest stracony dla danych - po prostu system będzie go zajmował w ostatniej kolejności. Efekt jest taki, że co prawda nie zapobiega to zupełnie fragmentacji, ale zdecydowanie odwleka ją w czasie.

Kopia zapasowa najważniejszych wpisów w MFT znajduje się w logicznym środku woluminu. Cała reszta dysku jest przeznaczona na pliki - wszystkie inne metadane też są trzymane w plikach, ale już nie mają ustalonego miejsca na dysku. Wszystkie metapliki poza MFT zajmują ok. 16KB, a pojedynczy wpis w MFT zajmuje stałą liczbę klastrów - ustalaną przy formatowaniu dysku (zazwyczaj 1).

Figure 3.2. Schemat struktury dysku w NTFS

Standardowy plik w NTFS posiada atrybuty: Standard_Information, File_Name, Security_Descriptor (co prawda zapisane gdzieś indziej, ale odnoszące się do pliku), Object_ID i Data. Czyli w skrócie przechowuje:

Dla przypomnienia - i-węzeł zwyczajnego pliku w ext2 przede wszystkim:

Jak widać te informacje są właściwie takie same. Nic dziwnego - jeśli chodzi o metadane trzymane przez systemy plików, to pewnie już dużo zrobić nie można. Wszystkie systemy trzymają właściwie takie same podstawowe informacje, oraz kilka specyficznych dla siebie - zazwyczaj służących do implementacji różnych rozwiązań, specyficznych dla danego systemu - takich jak np. Reparse_Point w NTFS. Informacje te pojawiają się zazwyczaj w stosunkowo niewielu plikach. Zwyczajny plik prawdopodobnie przez dłuższy czas jeszcze będzie wyglądał tak jak dzisiaj, chyba, że nastąpi jakaś rewolucja, na co na razie się nie zanosi. Nawet WinFS prawdopodobnie będzie przechowywał te wszystkie bazowe informacje.

Jak widać tutaj różnice między NTFS-em a ext3 są znaczne. Stanowią one dwa bieguny świata systemów plików. Zdecydowana większość innych systemów plików leży gdzieś po środku - kopiuje pewne rozwiązania z ext, a inne z NTFS. Np. XFS utrzymuje podział na grupy i bloki, ale już tablica i-węzłów jest rozszerzana według potrzeb. Trudno przewidzieć w jakim kierunku będą się rozwijały Linuksowe systemy plików chociażby dlatego, że obecnie nie ma zdecydowanego faworyta - część dystrybucji używa ext3, część ReiserFS. Microsoft idzie w kierunku bardziej bazodanowych systemów - o czym w dalszej częsci referatu (WinFS).

Jak już było wspomniane, atrybuty Index root, Index allocation i Bitmap dla danego katalogu pamiętają pliki i podkatalogi w nim zawarte. Opiszemy je pokrótce (są one istotną optymalizacją):

W systemach plików ext bardzo długo do utrzymywania zawartości katalogu wykorzystywano tylko prostych list łączonych. Listy takie bardzo dobrze spisywały się wobec tego, że VFS (Wirtualny system plików) za pomocą struktur dcache (wpisy dentry) bardzo dobrze optymalizuje dostępy do zawartości katalogu. Tym niemniej w przypadku pewnych aplikacji, takich jak cache przeglądarek czy systemy pocztowe korzystające z formatu Maildir, liniowa organizacja listowa powodowała istotne pogorszenie szybkości działania.

Z takich powodów rozważano dołączenie do ext2 struktur danych pokroju B-drzew do reprezentacji zawartości katalogu. Nie zdecydowano się jednak na to, gdyż byłoby to sprzeczne z ideą prostoty kodu przyświecającą temu systemowi plików (implementacja B-drzew w systemie plików XFS jest dłuższa niż cały kod źródłowy ext2 czy ext3!). Poza tym użytkownicy innych systemów plików informowali, że użycie B-drzew powoduje zwiększone szanse na utraty dużych ilości danych, kiedy jeden z wysoko położonych w B-drzewie węzłów ulegnie zniszczeniu.

Dlatego też do systemów plików ext (ext2 w wersjach rozwojowych, a oficjalnie włączone do ext3) wykorzystano inną strukturę danych o nazwie H-drzewa (Hash Trees), która jest specyficznie zoptymalizowana właśnie w kierunku przechowywania katalogów (jest to podejście inne niż w ReiserFS, JFS, XFS czy HFS, gdzie B-drzewa są używane na większą skalę). H-drzewa używają 32-bitowych haszy jako kluczy, a każdy klucz odpowiada przedziałowi nazw przechowywanych w bloku-liściu. Każdy wewnętrzny węzeł takiego drzewa zajmuje tylko 8 bajtów, co powoduje bardzo małe utraty przestrzeni dyskowej (ponad 500 bloków może zostać opisanych przy użyciu czterokilobajtowego bloku indeksowego). H-drzewa mają stałą głębokość (równą jeden lub dwa), w związku z tym nie wymagają używania operacji równoważących i ich implementacja jest o wiele prostsza.

Zadbano także o bardzo dobrą wsteczną kompatybilność struktury danych. Dlatego też bloki-liście są identyczne pod względem struktury z blokami starego typu, a bloki indeksowe są poprzedzone 8-bajtową strukturą, dzięki której stare wersje jądra Linuksa rozpoznają je jako usunięte wpisy katalogowe. Dzięki takiej organizacji łatwo jest także odzyskiwać dane o zawartości katalogu nawet przy zniszczeniu zawartości któregoś węzła wewnętrznego drzewa.

H-drzewa bardzo dobrze spisują się w praktyce, wiele operacji dyskowych na dużych katalogach jest dzięki nim wykonywanych nawet 50-100 razy szybciej.

W Ext2FS występuje teoretyczna możliwość kompresji plików - istnieje kilka wartości, które mogą być przypisane znacznikowi i_flags i-węzła z Ext2 - struktura ext2_inode i które świadczą o jego obsłudze w formie skompresowanej (EXT2_COMPR_FL - kompresowanie pliku, EXT2_COMPRBLK_FL - jeden lub więcej kompresowanych klasterów, EXT2_NOCOMP_FL - nie kompresować, EXT2_ECOMPR_FL - błąd kompresji). Chodzi tu oczywiście o kompresję przezroczystą (niewidoczną) dla użytkownika. W standardowej implementacji Ext2FS nie oferuje jednak możliwości kompresji plików - jest ona dostępna w łatach zawartych w pakiecie e2compr, które są dostępne od 1997 roku. Niestety Ext3FS w ogóle nie oferuje wsparcia dla przezroczystej kompresji plików, więc nawet nie można wykorzystać wyżej wymienionej łatki.

Z kolei - w przeciwieństwie do swoich Windowsowych poprzedników, czyli FAT-ów - NTFS oferuje możliwość kompresji plików za pomocą kilku mechanizmów. Można ustawić żądanie kompresji:

UWAGA: Zmiana parametru kompresji danego pliku powoduje natychmiastową zmianę jego stanu, a w przypadku folderów czy woluminów zmiana taka zmienia tylko parametr, jaki będzie przypisywany wszystkim nowym plikom i podkatalogom.

Istnieją dwie główne metody, jakie NTFS stosuje do kompresji plików:

Dodatkowo, NTFS udostępnia także specjalny typ rzadkiego pliku. Tego typu pliki są traktowane jak pliku skompresowane metodą kompresji rzadkich danych, ale nie są dokładnie tym samym. Mianowicie dany proces może wskazać pewne fragmenty pliku, które uznaje za puste i wtedy te fragmenty nie są pamiętane, a próba odczytu daje ciąg zer (jak powyżej). Tego typu pliki przydają się w aplikacjach typu klient-serwer, w których istnieje pewien bufor, do którego serwer pisze, a klient z niego czyta. Kiedy klient przeczyta pewien fragment pliku, to nie będzie on już informacji w nim zawartej potrzebował i może ustawić ten fragment jako pusty. Ten mechanizm pozwala uniknąć nieskończonego wzrostu wielkości plików. Inny przykład rzadkiego pliku stanowi bitmapa błędnych klastrów dyskowych, przechowywana jako omówiony już plik metadanych.

Hierarchiczna struktura systemu plików jest bardzo prosta i przejrzysta, ale niekiedy chcielibyśmy posiadać ten sam plik w dwóch różnych miejscach. Zawsze możemy zrobić jego kopię i umieścić ją w docelowym katalogu, ale to zajmowałoby jakże cenne miejsce na dysku.

Dlatego pojawiły się dowiązania. Rozróżniamy dwa rodzaje dowiązań:

Dowiązania w Linuksie są bardzo popularne i bardzo często używane. Tworzy się je poleceniem ln, przy czym uruchomienie z opcją -s tworzy link miękki.

Systemy plików ext zawierają informacje o plikach w i-węzłach. Wiele nazw plików może wskazywać na jeden i-węzeł. Każdy i-węzeł zawiera licznik odwołań, czyli liczbę nazw plików, które na niego wskazują. Tak więc stworzenie dowiązania polega po prostu na wpisaniu w pliku w polu i_node wskaźnika do odpowiedniego i-węzła oraz zwiększeniu jego licznika odwołań. Kiedy dowiązanie jest usuwane, licznik odwołań zostaje zmniejszony przez jądro i jeżeli osiągnie on wartość 0, to i-węzeł jest zwalniany. Na tej właśnie zasadzie działają w Linuksie dowiązania twarde.

Twarde dowiązania muszą być używane w ramach jednego systemu plików. Co więcej nie można tworzyć twardych dowiązań do katalogów, aby zapobiec tworzeniu się cykli w drzewie katalogów.

Jeżeli chodzi o dowiązania miękkie, to zawierają one tylko ścieżkę do pliku właściwego. Kiedy jądro napotyka miękkie dowiązanie podczas pobierania i-węzła, to po prostu przechodzi do ścieżki przez niego wskazywanej. Ponieważ miękkie dowiązanie nie wskazuje bezpośrednio na i-węzeł, to jest możliwe tworzenie takich dowiązań do innych (nawet nieistniejących) dysków. Są one bardzo użyteczne, jako że nie mają tylu ograniczeń jak dowiązania twarde, jednak dostęp do nich jest trochę wolniejszy, jako że jądro musi "od początku" odczytać plik wskazywany przez dowiązanie, a także takie dowiązanie jest plikiem, wiec zajmuje i-węzeł na dysku. Jednak i tak są one bardzo popularne i często używane (za ich pomocą można już tworzyć dowiązania do katalogów).

Twarde dowiązania w systemie operacyjnym Windows nie są obsługiwane na katalogach. Aby stworzyć twarde dowiązanie, należy użyć funkcji CreateHardLink lub ln.

Dodatkowo występują także dowiązanie miękkie, czyli tak zwane junctions. "Tłumaczą" one ścieżki w taki sposób, że jeżeli przykładowo katalog c:\temp jest dowiązaniem wskazującym na c:\windows\temp, to program czytający plik c:\temp\a.in naprawdę przeczyta plik c:\windows\temp\a.in. Jest to bardzo użyteczne nie tylko do lepszego układania danych, ale także do stworzenia prostych ścieżek do katalogów, które znajdują się głęboko w hierarchii.

Dowiązania miękkie bazują na mechanizmie reparse points (nie istnieje znane nam dobre polskie tłumaczenie tego terminu, więc pozostaniemy przy oryginale anglojęzycznym). Reparse point to plik lub katalog który posiada atrybut reparse data, w którym jest informacja o lokalizacji oryginalnego pliku. Dodatkowo każdy plik reparse posiada unikalny reparse tag, dzięki czemu jeżeli następuje po raz któryś odwołanie do tego samego pliku reparse, to system nie musi odczytywać informacji z reparse data.

Kiedy NTFS napotyka plik typu reparse to zwraca reparse status code, który informuje system plików, aby ten przegjrzał reparse data. Program odpowiedzialny za dostarczanie danych (czyli system plików lub wejścia/wyjścia) wybiera wówczas jedną z dwóch możliwości:

W systemach Windows bardzo popularne stały się skróty do plików. Jest to bardzo wygodne narzędzie i często stosowane, ale we wcześniejszych wersjach systemu Windows problem pojawiał się, gdy plik, na który skrót wskazywał zostawał przeniesiony. Wtedy Windows starał się go odnaleźć używając rożnego rodzaju heurystyk, które niekoniecznie szybko i skutecznie prowadziły do jego odnalezienia. Podobne problemy pojawiały się przy wykorzystywaniu ideologicznie podobnego mechanizmu OLE (object linking and embedding), który pozwala m.in. na wygodne przenoszenie dokumentów między różnymi aplikacjami pakietu Microsoft Office (Power Point, Word czy Excel).

NTFS zawiera wsparcie do usługi zwanej "distributed link tracking" czyli do usługi śledzenia dowiązań. Usługa ta sprawia, że dowiązania dalej wskazują na poprawne pliki, nawet jeżeli te pliki zostały przesunięte, pod warunkiem jednak, że pozostają w tej samej domenie.

Śledzenie jest w głównej mierze oparte na atrybucie pliku o nazwie Object ID. Dzięki temu system ma możliwość śledzenia zmian umiejscowienia pliku, tak aby dowiązania pozostawały poprawne.

Quota jest wygodną funkcjonalnością systemów plików, umożliwiającą limitowanie miejsca dyskowego, z którego użytkownik może korzystać. Jest to szczególnie ważne na wielkich serwerach z tysiącami użytkowników, aby użytkownicy nie mogli całkowicie zapchać dysków.

Ogólnie istnieją dwa rodzaje limitów, które są przyznawane:

Na większości serwerów są ustawione limity quoty nie tylko na ilość miejsca zajętego, ale także na np. maksymalną liczbę plików danego użytkownika plików. W większości przypadków oba rodzaje limitów kontyngentów, czyli twarde i miękkie, występują równolegle (czyli każdy użytkownik ma ustawiony jakiś miękki limit i odpowiednio wyższy od niego limit twardy).

W Linuksie quota jest bardzo popularna i prosta w użyciu. Została włączona do jadra Linuksa już od wersji 1.3.8, ale zadomowiła się na dobre w wersji 2.0.

Informacje o limitach dla użytkowników i grup znajdują się jako plik na dysku, na którym owa quota ma być wymuszana. Z reguły jest to plik quota.user lub quota.group w głównym katalogu.

W pliku znajduje się tablica struktur indeksowana po uid lub gid, jedna struktura na dla każdego id użytkownika, niezależnie czy użytkownik ma ustawioną quotę czy nie.

System jest informowany o obecności pliku z limitami przez wywołanie funkcji quotactl. Wtedy wczytuje on limity, najpierw dla użytkowników i grup aktualnie zalogowanych, a później dla pozostałych. Od tej pory każde otwarcie pliku w systemie będzie wiązało się ze sprawdzeniem limitów.

W większości przypadków informacje o limitach danego użytkownika będą przechowywane w pamięci, gdyż często użytkownicy otwierają wiele plików jeden po drugim.

W pamięci informacja o limitach jest trzymana jako hash z uid. jeżeli jeden użytkownik dokonuje wielu operacji dyskowych jedna po drugiej, quota będzie więc sprawdzana bardzo szybko.

Teraz, za każdym razem gdy następuje dostęp do bloku, albo jakiś i-węzeł jest tworzony lub zwalniany, program zarządzający quotą jest o tym informowany i może przerwać operacje. Badania wykazały, że koszt sprawdzania quoty stanowi bardzo mały procent czasu zapisywania nowego bloku na dysk.

W systemie Windows długo nie było wsparcia dla quoty, pojawiło się dopiero wraz NTFS-em.

Quota w systemie NTFS pozwala na ustawienie limitu dla każdego użytkownika z osobna, można również ustawić opcję logowania każdego zdarzenia które przekracza limit. Jeżeli program użytkownika przekracza limit dyskowy, to próba alokacji nowego kawałka dysku kończ y się błędem "disk full".

Ustawienie limitów w Windowsie jest bardzo proste, co pokazuje poniższy obrazek:

Figure 12.1. Ustawianie quoty w systemie operacyjnym Windows

Jak widać można ustawić "warning level", co odpowiada limitowi miękkiemu, oraz "limit disk space", co odpowiada limitowi twardemu. Dodatkowo po kliknięciu w Quota Entries możemy ustawić inne limity aktualnym użytkownikom.

NTFS przechowuje informacje o limitach w pliku \$Extend\$Quota, który zawiera tabele $O i $Q. NFTS przydziela każdemu użytkownikowi unikalny numer UserID. Kiedy administrator ustawia limit dla użytkownika, NTFS przypisuje jego Security ID (SID) numer użytkownika User ID oraz w tabeli $Q zamieszcza informacje o limitach dla danego użytkownika. Informacja w tabeli $Q zawiera nie tylko wartość limitu, ale także ilość aktualnie zajętego miejsca.

Przy liczeniu sumarycznego miejsca zajmowanego przez użytkownika, rozmiar pliku jest liczony na podstawie jego nominalnej wielkości a niekoniecznie ilości faktycznego miejsca zajętego na dysku. Chodzi tu zwłaszcza o rzadkie pliki czy sytuacje, gdy jest włączona kompresja dysku. Wtedy nawet jeżeli plik o rozmiarze 50 KB po skompresowaniu zajmuje na dysku tylko 10 KB, to cała jego wielkość (czyli 50 KB) zostanie uznana jako używana przez użytkownika.

Poniżej znajduje się obrazek ilustrujący wygląd tabel $O i $Q:

Figure 12.2. Plik informacji o quocie

Kiedy aplikacja tworzy plik, NTFS bierze Security ID danej aplikacji i wyszukuje odpowiadający jej numer User ID w tabeli $O. Później sprawdza w tablicy $Q czy stworzenie danego pliku nie przekroczy limitów. Jeżeli przekracza, to NTFS odmawia stworzenia pliku i rejestruje ten fakt w logach systemowych. W przeciwnym przypadku NTFS uaktualnia dane o ilości zajętego przez danego użytkownika miejsca.

System plików, otrzymując żądania wykonania operacji, może szeregować poszczególne ich elementy 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 próbuje bronić się 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 by nie były krytyczne, tak aby system mógł je naprawić w dogodnym momencie, a nie było konieczne dogłębne sprawdzanie systemu podczas uruchomienia. Na przykład 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, to 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 kolejno, gdyż przeplatanie operacji może prowadzić do powstawania niespójności.

Ostrożne zapisywanie poświęca szybkość operacji dla względnego bezpieczeństwa, a drugie podejście jest zupełnie inne. Zapisywanie leniwe zapisuje w cache'u operacje, a następnie wykonuje je w zoptymalizowanej kolejności. Daje to wzrost wydajności z dwóch powodów: po pierwsze 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, to system może znajdować się w niespójnym stanie. Z tego powodu większość administratorów korzystających np. z systemu plików ext2, z namaszczeniem kilkakrotnie wpisywało komendę sync przed przeładowaniem systemu, traktując ją jak zaklęcie mające ustrzec ich przed błędami powstającymi na dysku.

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? Po co w ogóle rozpatrujemy bezpieczeństwo systemu plików? Odpowiedź na to pytanie jest prosta - ponieważ większość danych zapisujemy na dyskach, które mają pewne ograniczenia, gdyby natomiast istniała tania, szybka, trwała (nieulotna), niezawodna i bardzo pojemna pamięć operacyjna, to dyski twarde nie byłyby już wówczas potrzebne. Nie zapewniłoby to pełnego bezpieczeństwa systemu plików, ale mogłoby usunąć jedną z najczęstszych przyczyn powstawania błędów. Przyczyny powstawania błędów można podzielić na dwie zasadnicze grupy:

Wśród logicznych błędów na dysku, czy też mówiąc inaczej - niespójności metadanych systemu plików z właściwą zawartością dysku, możemy wyróżnić kilka najpopularniejszych:

Wydawać by się mogło z punktu widzenia użytkownika, że wszystkie operacje na dysku pokroju usunięcia pliku powinny być atomowe, jednak w rzeczywistości 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.

Można się zastanawiać dlaczego atomowość operacji ma znaczenie. Przyjrzyjmy się dla przykładu operacji usuwania pliku w systemie UNIX - składa się ona co najmniej z dwóch kroków: najpierw następuje usunięcie wpisu w katalogu, następnie i-węzeł pliku ustawiany jest 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 i czasochłonne 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.

Jak widać z powyższego przykładu ważne jest aby połączenie obu tych operacji było atomowe - wykonały się albo obie pomyślnie, albo też żadna z nich nie odniosła skutku, gdyż w ten sposób system plików z pewnością będzie w stanie spójnym.

Aby zapewnić atomowość operacji, część systemów plików zapożyczyło metodę utrzymywania atomowości operacji (które od tego momentu będziemy nazywać transakcjami) z systemów baz danych. Wykorzystują one do tego celu dziennik zwany też częściej w przypadku systemów plików kroniką. Kronika 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 znajduje się w spójnym stanie, przed udostępnieniem go użytkownikowi.

Głównym celem kroniki jest zachowanie abstrakcji atomowości operacji na systemie plików, co pozwala zachować jego spójność.

Kronika ma niezaprzeczalne zalety, jakimi są:

Jednak kroniki mają też pewne wady, do których możemy zaliczyć m.in.:

Jak już to zostało wspomniane, dzisiejsze systemy plików stosują technikę rejestrowania zapożyczoną z systemów baz danych. Istnieją dwie podstawowe metody rejestrowania transakcyjnego:

Większość systemów plików z kroniką korzysta z rejestrowania odtwarzającego, jak to ma miejsce m.in. w przypadku systemu ext3, natomiast NTFS częściowo łączy w sobie obie techniki.

Poprzedni podział dotyczył trybów kronikowania, możemy też wyróżnić podział ze względu rodzaj danych podlegających kronikowaniu:

Możemy wymagać od systemu plików, by w dzienniku zapisywał zmiany dokonywane tylko w odniesieniu do metadanych, jak również wszelkie zmiany dotyczące zarówno danych i metadanych. Rejestrowanie wszystkich 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ę między zapisywaniem tylko operacji dotyczących metadanych a zapisywaniem wszystkich zmian, rozważmy przykład dopisywania danych na końcu pliku. W systemie Linux mogłoby to wyglądać w sposób następujący:

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ć niepoprawne dane na końcu.

Może się zdarzyć, że systemy plików znajdują się w stanie niespójnym, gdyż kroniki nie chronią nas explicite przed powstawaniem niespójności, lecz pozwalają je naprawić. W tym celu przydatne może okazać się odtwarzanie dzienników. Można się zatem zastanawiać kiedy systemy plików wykonują analizę zapisu kroniki, w przypadku nieprawidłowego zamknięcia systemu plików (nie jest ustawiony bit poprawnego odmontowania). Systemy plików odtwarzają dane zapisane w dzienniku:

Większość systemów (w tym NTFS, ext3, XFS, ReiserFS, Reiser4) wykonuje 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).

Kolejnym aspektem związanym z dziennikami jest ich położenie na dysku. Systemy plików z kroniką mogą się w sposób znaczący różnić umiejscowieniem pliku z kroniką w systemie. Można wyróżnić co najmniej trzy metody przechowywania ich na dysku:

Za dość istotne uznaliśmy również opisanie systemu ext3 i sposobu, w jaki rozszerza on istniejący system ext2, a także konsekwencji z tym związanych. W skrócie zależność między tymi systemami można przedstawić w postaci równania:

Wspomniane już zostały też pozostałe różnice, jakimi są np. H-drzewa, jednak sposób ich zaimplementowania zapewniał wsteczną zgodność z systemem ext2. Najważniejszą jednak różnicą, która spowodowała powstanie nowego systemu plików jest wzbogacenie systemu ext2 o funkcje dziennika. Autorzy systemu ext3 przed jego powstaniem stanęli przed dylematem, czy tworzyć od początku nowy system plików, czy oprzeć się już na jakimś istniejącym, dobrze przetestowanym systemie, jakim bez wątpienia jest system ext2. Pierwszym co zrobiono przy tworzeniu systemu ext3, było skopiowanie kodu źródłowego ext2 i zmiana wszystkich wystąpień ext2 na ext3. Następnie zostało zaprojektowane urządzenie kronikujące (journaling blok device), które odpowiada za prowadzenie dziennika i może być również wykorzystane przez inne komponenty systemu operacyjnego, które chciałyby udostępniać funkcję kroniki. Aby zachować zgodność, kronika jest po prostu jednym z plików w systemie. Ten sposób implementacji sprawia, że system ten jest praktycznie w 100% zgodny z ext2. Ma to daleko idące konsekwencję - gdyż m.in. możemy używać do niego narzędzi zaprojektowanych dla systemu ext2, jak dump i restore, a sam program fsck.ext3 jest również dowiązaniem symbolicznym do e2fsck. Proces konwersji między systemami jest również całkowicie odwracalny, gdyż z jednej strony poprawnie odmontowany system ext3 może być bez najmniejszych problemów zamontowany jako system ext2, jednocześnie konwersja z systemu ext2 do ext3 sprowadza się do wykonania jednego polecenia tune2fs, tworzącego dziennik. Ma to bardzo ważne konsekwencje, gdyż na świecie znajduje się jeszcze wiele serwerów czy komputerów domowych korzystających z systemu ext2 - możemy zatem bardzo łatwo wzbogacić te systemy o funkcję kroniki, a co za tym idzie zwiększyć poziom bezpieczeństwa zapisanych na nich danych, bez potrzeby długotrwałej i dodatkowo narażającej na błędy operacji migracji do całkowicie innego systemu plików. Możliwość łatwej konwersji pozwala także na wykorzystanie w systemie plików ext3 pewnych narzędzi, których w przeciwieństwie do ext2 nie posiada - jak na przykład narzędzia do defragmentacji e2defrag.

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. Niektóre przykłady kiedy do takiej sytuacji może dojść można znaleźć w pracy [FailureAnalysis], gdzie autorzy skupiają się na niedociągnięciach implementacji kronikowania w różnych Linuksowych systemach plików (w tym wypadku ext3, ReiserFS orax JFS). Jako przykład można przytoczyć sytuację odnoszącą się do systemu ext3, który w wypadku niepowodzenia zapisu fragmentu transakcji, kontynuuje jej zapis i może ją zatwierdzić, zanim błędy w zapisie zostaną skorygowane, co może prowadzić do rozspójnienia systemu. Akcje jakie mogą być podjęte przeż użytkownika (administratora) systemu, aby przywrócić system do spójnego stanu wobec awarii dziennika to:

fsck.xfs(8)                                                                                           fsck.xfs(8)

NAME
       fsck.xfs - do nothing, successfully

SYNOPSIS
       fsck.xfs [ ...]

DESCRIPTION
       fsck.xfs  is called by the generic Linux fsck(8) program at startup to check and repair an XFS filesystem.
       XFS is a journaling filesystem and performs recovery at mount(8) time if  necessary,  so  fsck.xfs  simply
       exits with a zero exit status.

       If  you  wish  to  check  check  the  consistency of an XFS filesystem, or repair a damaged or corrupt XFS
       filesystem, see xfs_check(8) and xfs_repair(8).

FILES
       /etc/fstab.

SEE ALSO
       fsck(8), fstab(5), xfs(5), xfs_check(8), xfs_repair(8).

                                                                                                      fsck.xfs(8)
(END)

Zauważmy, że wprowadzenie kronikowania do systemu plików, poza problemami natury wydajnościowej niesie ze sobą dodatkowe problemy koncepcyjne, związane z semantyką operacji wykonywanych na plikach.

Istnieją teraz pewne operacje, które należy wykonywać ze szczególną dozą ostrożności tak, aby nie doprowadziły one do rozspójnienia systemu. Rozważmy następujące przykłady:

Drugi z tych przykładów tak na prawdę symbolizuje szersze wymagania odnośnie poleceń ponawiania i wycofania, zapisanych w dzienniku systemu plików. Mianowicie muszą one mieć taką postać, aby gwarantowały, że ponowienie wykonanych (ale nie zatwierdzonych) operacji lub wycofanie niewykonanych operacji nie prowadziło do powstawania niespójności.

W rozdziale tym postaram się dokładnie opisać sposób realizacji mechanizmu kronikowania w systemie plików NTFS (został on zaczerpnięty wraz z obrazkami z książki [Internals]).

W przypadku NTFS, mamy do czynienia z sytuacją podobną jak w ext3, funkcje kroniki realizowane są przez odrębny moduł, powiązania między modułami wyglądają w sposób następujący:

Figure 13.1. Schemat komunikacji

Ja widać system plików odwołuje się do modułu odpowiadającego za kronikowanie, zapewniającego abstrakcję kroniki i udostępniającego systemowi plików proste operacje na transakcjach. Sam menedżer kronikowania korzysta z menedżera cache'u w celu dostępu do pliku, gdzie zachowuje właściwe dane związane z kroniką.

Plik z kroniką w systemie NTFS składa się z dwóch części:

Figure 13.2. Schemat pliku z logiem

System wykonuje operację jednocześnie gwarantując, że system plików może być zawsze odzyskany do stanu spójnego w następujący sposób:

Przy pierwszym dostępie do systemu plików sprawdzane jest, czy w dzienniku nie ma transakcji, które nie zostały utrwalone na dysku.

13.2. Przywracanie spójności systemu przy pomocy kroniki

Jak to już zostało wcześniej wspomniane, system NFTS przystępuje do operacji odzyskiwania dziennika przy pierwszym dostępie do systemu plików. Proces ten zależy od dwóch tablic:

• tablicy transakcji - przechowuje informacje o transakcjach, które zostały rozpoczęte, ale nie zostały zatwierdzone; wszystkie podoperacje tych aktywnych transakcji muszą zostać wycofane podczas przywracania spójności,

• tablica brudnych stron - przechowuje informacje o tym, które strony w cache'u zawierają modyfikacje systemu plików, które nie zostały zapisane na dysk. Te dane muszą być utrwalone na dysku.

NTFS co 5 sekund zapisuje rekord z punktem kontrolnym do dziennika, tuż przed tym zachowywana w kronice jest także aktualna kopia wyżej wymienionych tablic, następnie w rekordzie kontrolnym zapisuje numery rekordów zawierających te tablice. Podczas procesu odzyskiwania danych odszukiwane są najświeższe kopie tych tablic i wczytywane są do pamięci.

Kronika zwykle zawiera jeszcze rekordy uaktualnień znajdujące się za ostatnim punktem kontrolnym. Reprezentują one zmiany, które zaszły później, więc system musi uwzględnić te zmiany w tablicach transakcji i brudnych stron. Po uaktualnieniu tablic zmiany są utrwalane na dysku twardym.

NTFS skanuje dziennik trzy razy, jednak przy pierwszym przebiegu zapisuje go sobie w pamięci, aby zminimalizować liczbę odczytów z dysku. Każdy z tych przebiegów ma określony cel:

• faza analizy kroniki,

• faza ponawiania operacji,

• faza wycofywania operacji.

Analiza kroniki.

Podczas analizy kroniki jest ona przeglądana od początku ostatniego punktu kontrolnego, aby znaleźć rekordy uaktualnień i wykorzystać je do wprowadzenia zmian do tablicy transakcji i brudnych stron. Jak widać na obrazku punkt kontrolny tak naprawdę składa się z trzech rekordów, przez co rekordy uaktualnień mogą być z nimi przemieszane, dlatego system musi zacząć skanowanie od początku ostatniego punktu kontrolnego.

Figure 13.5. Faza analizy kroniki

Większość rekordów uaktualnień zapisanych po punkcie kontrolnym reprezentuje modyfikacje albo tablicy transakcji albo tablicy brudnych stron. Jeśli rekord jest np. rekordem zatwierdzającym transakcję, wówczas odpowiedni rekord odpowiadający tej transakcji musi zostać usunięty z tablicy transakcji. Następnie system wyznacza numer najstarszej operacji, która nie została utrwalona na dysku. Tablica transakcji zawiera na koniec numery niezatwierdzonych operacji, natomiast tablica brudnych stron zawiera numery rekordów cache'u, które nie zostały utrwalone na dysku. Numer tej transakcji wyznacza moment, od którego rozpocznie się faza odtwarzania.

Ponawianie operacji.

Podczas fazy ponawiania dziennik jest również przeglądany do przodu rozpoczynając od numeru rekordu wyznaczonego w czasie analizy. System szuka rekordów z uaktualnieniami stron, które następnie są ponawiane.

Figure 13.6. Faza ponawiania operacji

Ja tylko system dojdzie do końca logu, w cache'u znajdują się uaktualnione informacje, które następnie menedżer cache'u leniwie zapisze na dysk.

Wycofywanie operacji.

Po ukończeniu operacji ponawiania system przegląda dziennik od tyłu, wycofując wszelkie niezatwierdzone transakcje. Na rysunku widzimy dwie transakcje, z których pierwsza została zatwierdzona przed awarią systemu, natomiast druga nie. Zatem NTFS musi wycofać drugą transakcję.

Figure 13.7. Faza wycofywania operacji

Po ukończeniu fazy wycofywania operacji wolumin znajduje się w stanie spójnym. W tym miejscu następuje wymuszenie zapisu wszystkich danych na dysk i zapisywany jest pusty rekord w rekordzie startowym dziennika oznaczający, że system jest spójny. Na tym cały proces przywracania spójności się kończy.

Pomimo ewolucji dzisiejszych systemów plików nie są one jednak w stanie ochronić nas przed wszelkimi możliwymi awariami, dlatego jeśli naprawdę zależy nam na naszych danych (a w dzisiejszym świecie, często to one, a nie sprzęt stanowią największą wartość) powinniśmy rozważyć przedsięwzięcie dodatkowych środków, mogących zabezpieczyć nas przed ewentualną katastrofą. Pokrótce opiszemy kilka sposobów, dzięki którym będziemy mogli spać spokojniej, wierząc, że nasze dane są bezpieczniejsze:

Generalnie nie stanowi to większego problemu, gdyż dla większości systemów plików o otwartej specyfikacji istnieją odpowiednie moduły do jądra, obsługujące dany system plików. Jedyny problem stanowią systemy o zamkniętej specyfikacji - jak to ma miejsce np. w przypadku NTFS. Co prawda istnieją standardowe moduły jądra, obsługujące podstawowe operacje na tym systemie plików, lecz w zasadzie ograniczają się one wyłącznie do odczytu - możliwa jest co prawda modyfikacja, jednak nie może ona zmieniać rozmiaru pliku. Istenieją też komercyjne produkty dla Linuksa, umożliwiające pełen dostęp do systemu NTFS - jednym z takich programów jest Paragon NTFS for Linux .

Tu sprawa wygląda również obiecująco, gdyż dla większości linuksowych systemów plików istnieją OpenSource'owe narzędzia, służące do dostępu do danych zapisanych na tych partycjach. Jest wiele programów umożliwiających dostęp do systemu ext2, np. programy takie jak: FSDext2, explore2fs. Istnieją również wtyczki (pluginy) do popularnego menedżera plików (TotalCommander) umożliwiające odczyt z systemów ext2, ext3 oraz ReiserFS.

Po bardziej szczegółowe informacje odnośnie dostępu do linuksowych systemów spod Windows oraz windowsowych spod Linuksa odsyłamy do pliku HOW-TO oraz do artykułu.

Kiedy użytkownik po raz pierwszy coś szyfruje, jest dla niego tworzona para kluczy, publiczny i prywatny. Będą mu one służyły dalej do szyfrowania i deszyfrowania plików. Kiedy szyfrujemy dany plik, to jest dla niego tworzony w EFS tak zwany FEK, czyli File Encryption Key (będący pewną losową wartością przypisaną temu plikowi). Za pomocą FEK zawartość pliku jest szyfrowana tudzież deszyfrowana przy użyciu symetrycznego algorytmu szyfrowania, jakim jest w Windowsie 2000 i Windowsie XP algorytm DESX (silniejszy wariant DES-a), zaś w Windowsie XP z Service Pack 1 i Windowsie 2003 Server - AES (Advanced Encryption Standard). Jest także możliwość włączenia jeszcze silniejszego algorytmu szyfrowania, mianowicie 3DES. Symetria algorytmu polega na tym, że tym samym kluczem plik można szyfrować i deszyfrować.

Po co nam w takim razie klucz publiczny i prywatny użytkownika? Otóż kluczem publicznym użytkownika jest szyfrowany FEK (gdyż jego postać niezaszyfrowana, jak już zostało wspomniane, pozwalałaby na natychmiastowe odszyfrowanie pliku) i taka zaszyfrowana kopia jest trzymana dla danego pliku dla każdego użytkownika, który ma mieć możliwość ten plik szyfrować i deszyfrować. Taka właśnie metoda została wybrana, gdyż szyfrowanie symetryczne jest o wiele szybsze od niesymetrycznego, a więc do dużych partii danych (zawartość pliku) używany DESX-a lub AES-a, zaś do samego tylko FEK-a używamy RSA (klucz publiczny i prywatny).

W szyfrowaniu najważniejszym (i wymagającym największego bezpieczeństwa) punktem jest więc klucz prywatny. Klucz ten jest przechowywany w katalogu profilu użytkownika (\Documents and Settings) w podkatalogu Application Data\Microsoft\Crypto\RSA (w polskojęzycznej wersji Windowsa często katalog Application Data ma nazwę Dane aplikacji). Dla jego ochrony, wszystkie pliki katalogu RSA są szyfrowane za pomocą losowego 64-bajtowego klucza symetrycznego, tzw. master key, który jest specyficzny dla użytkownika. Ten z kolei jest przechowywany w katalogu Application Data\Microsoft\Protect i jest zaszyfrowany za pomocą algorytmu 3DES z użyciem klucza, którego część jest oparta na haśle danego użytkownika. Tak więc zmiana hasła użytkownika powoduje odszyfrowanie jego master key i ponowne zaszyfrowanie z użyciem nowego hasła.

Sterownik EFS działa w trybie jądra (podobnie zresztą jak sterownik NTFS, a w nowszych wersjach jest w niego wbudowany). Kiedy tylko NTFS napotyka zaszyfrowany plik, wywołuje stosowne funkcje EFS, które zajmują się szyfrowaniem i deszyfrowaniem danych na żądanie dostępu wykonane przez aplikację użytkownika. Aby jednak odszyfrować FEK-a danego pliku, EFS musi wykorzystać klucz prywatny użytkownika z pomocą funkcji kryptograficznych, działających w trybie użytkownika. Za pomocą sterownika KSecDD zostaje wywołana odpowiednia funkcja, która znajduje się w LSASS (Local Security Authority Subsystem, który odpowiada za zarządzanie sesjami, ale także kluczami EFS) - komponentem LSASS-a wysłuchującym takie żądania jest Lsarv (Local Security Authority Server). On to zleca CSP (cryptographic service provider) poprzez Microsoft CryptoAPI (CAPI) żądanie odszyfrowania FEK-a, które ten wykonuje, po czym Lsarv zwraca EFS-owi odszyfrowany klucz.

Jak wiadomo systemy plików były kwestią, którą zajmowano się prawie od samego początku istnienia komputerów. Jednakże jeszcze kilkanaście lat temu, projektujący nie skupiali się na optymalizowaniu wyszukiwania plików, gdyż w tamtych czasach pojemności dysków nie przekraczały kilku megabajtów. Jednakże w dzisiejszym świecie, przy dzisiejszych olbrzymich dyskach i wielkich ilościach plików kwestia szybkiego wyszukiwania staje się coraz ważniejsza.

Aktualne systemy plików działają dość szybko, oraz dobrze zarządzają miejscem na dysku. Dodatkowo metadane również zajmują niewielką ilość miejsca. Jednakże wszystkie aktualne systemy plików mają strukturę hierarchiczną. To oznacza, że dla każdego pliku wiemy, w jakim katalogu się znajduje i dla każdego katalogu wiemy, jakie zawiera pliki. Każdy plik posiada w tym momencie unikalną ścieżkę, dzięki której możemy go znaleźć. Jest to bardzo prosta, ale też bardzo szybka struktura, do której wszyscy zdążyli się już przyzwyczaić.

Jednak największą jej wadą jest brak możliwości tworzenia dodatkowych połączeń miedzy plikami. Próbą rozwiązania tego problemu jest tworzenie linków, dzięki czemu odnosi się wrażenie, że plik jest w kilku miejscach naraz. Dodatkowo wprowadza się dodatkowe atrybuty do pliku, co umożliwia dodanie dodatkowych informacji i późniejsze wyszukiwanie po nich.

Jednak ciągle wyszukiwanie jest bardzo kosztowne. Aktualnie próby radzenia sobie z tym problemem polegają na indeksowaniu i cache'owaniu zapytań, wiec przy założeniu, że użytkownik zadaje pytania o podobne pliki, ten algorytm działa, jednak przy złośliwych przypadkach użytkownik może bardzo długo czekać na interesujące go pliki.

Ideą "nowego podejścia" jest powiedzenie, że wszystko jest relacją. WinFS będzie wykorzystywał bazę danych do przechowywania plików. Pod tą wartwą będzie system plików NTFS, będzie również dostępny "stary" API, dzięki czemu będzie zachowana wsteczna kompatybilność.

Głównymi zaletami takiego podejścia są bardzo wydajne możliwości wyszukiwania w takim systemie. Jak wiadomo bazy danych są pisane pod kątem optymalizacji wyszukiwań, więc wyszukiwanie plików zarówno po ich nazwach jak i atrybutach będzie bardzo szybkie. Dodatkowo wielką zaletą będzie możliwość dodawania "połączeń" między plikami, ich grupowania po pewnych cechach itp.

Z punktu widzenia użytkownika nie będzie struktury hierarchicznej. Znaczy się, jeżeli ktoś będzie chciał to będzie mógł tworzyć zagnieżdżone katalogi itp. itd., ale one nie będą w ten sposób przechowywane na dysku.

Głównymi wadami WinFS-a są oprócz tego, że metadane zabiorą o wiele więcej miejsca, to koszt wielu operacji się powiększy. Dodatkowo każdy kto używał bazy danych, wie że w dużym stopniu wykorzystuje ona pamięć operacyjną i czas procesora. Tak więc wymagania sprzętowe WinFS-a będą istotną kwestią.

Dodatkowo bardzo poważną wadą może okazać się brak dostępu spod innych systemów operacyjnych. Już w NTFSie pojawiają się problemy z zapisem plików spod Linuksa, więc nie wiadomo, jak będzie wyglądała sytuacja w stosunku do WinFS. Czas pokaże. Jedną z najważniejszych wad WinFS jest także to, że nie pojawi się wcześniej niż w roku 2007.

Na poniższym obrazku znajduje się struktura WinFS-a. Jak widać bazuje on na systemie plików NTFS oraz na nowym "engine" SQL-a Yukonie, który też jeszcze nie został wypuszczony.

Figure 16.1. Struktura WinFS