Prezentacja "Unixowe systemy plików"

dyskowe - wszystkie pliki są trzymane fizycznie na dysku twardym
bazujące na pamięci operacyjnej - są utrzymywane tylko do momentu wyłączenia komputera w pamięci RAM

Ogólnie jednak pomysł i implementacja były podobne dla obu tych rodzajów. Poprzez ostatnie 10 do 15 lat powstało kilka pseudo systemów plików, które z punktu widzenia użytkownika wyglądają normalnie, ale których implementacja jest inna ze względu na brak fizycznego położenia. Systemy te będą omówione w jednym z kolejnych rozdziałów, a teraz zajmiemy się ogólnym omówienie dyskowych systemów plików.

UNIXowy system plików to zbiór plików i katalogów o następujących własnościach:

posiada katalog główny (/), który zawiera pozostałe pliki i katalogi [większość systemów plików posiada również katalog "lost+found", gdzie znajdują się pliki odzyskane po nieprawidłowym zamknięciu systemu UNIX ]
każdy plik (katalog) jest jednoznacznie identyfikowalny przez swoją nazwę, katalog w którym się znajduje oraz i-węzeł
zasadniczo katalog główny ma i-węzeł numer 2, katalog "lost+found" numer 3. I-węzły 0 oraz 1 są nieużywane. [Numery i-węzłów poszczególnych plików można wyświetlić poleceniem "ls -i"]
jest samowystarczalny. Nie ma zależności pomiędzy jednym systemem plików a innym

System plików musi być w stanie "czysty" żeby mógł zostać zamontowany. W przypadku gdy system się zawiesi system plików ustawiany się odpowiednio jako "brudny". Ponieważ operacje na plikach w tym wypadku mogły nie zostać zakończone pomyślnie system plików może nie być spójny i wymaga sprawdzenia oraz naprawy. Tą czynnością zajmuje się program "fsck", który przywraca system plików w stan "czysty".

Wirtualny system plików

Żeby mówić o różnych systemach plików fizycznie zarządzających tymi plikami należy bez wątpienia wspomnieć o Wirtualnym Systemie Plików (VFS). Fizyczny system plików nie jest bezpośrednio dostępny dla użytkownika z wielu różnych przyczyn (m.in. chęci uzyskania wspólnego interfejsu odwołań do plików) i właśnie poprzez VFS odbywa się komunikacja między nimi. W momencie gdy użytkownik wywołuje komendę VFSa jest ona odpowiednio tłumaczona na polecenie wysyłane do fizycznego systemu plików.
Twórcy VFSa postawili sobie cztery główne cele:

Implementacja systemu plików powinna być jasno podzielona na warstwę zależna od niego i niezależną. Interfejs pomiędzy nimi dwoma powinien być dobrze zdefiniowany.
Powinien wspierać lokalne systemy plików (FFS), a także nie Unixowe (MS-DOS) i bezstanowe (NFS)
Powinien być w stanie wspierać serwer rozproszonych systemów plików
Operacje systemu plików poprzez interfejs powinny być atomowe tak, aby nie potrzebowały blokad

Główne składniki systemu VFS pokazane są na poniższym rysunku:

Architektura systemu plików VFS

Dysk i partycje ...

Każdy dysk twardy jest zazwyczaj podzielony na kilka oddzielnych partycji, które mogą mieć niemal dowolne rozmiary [zależnie od systemu plików i oczywiście pojemności samego dysku]. Każdy dysk zawiera tablicę partycji, która opisuje gdzie zaczynają się poszczególne partycje oraz jaki jest ich rozmiar. Każda z partycji może być użyta do przechowywania informacji startowych (bootstrap), systemu plików lub innego celu.

Dyskiem możemy zarządzać przy pomocy wielu różnych narzędzi. Poniższy przykład pokazuje partycje na dysku Linuxowym [przy użyciu programu fdisk]:

# fdisk /dev/hda
Command (m for help): p
Disk /dev/hda: 240 heads, 63 sectors, 2584 cylinders
Units = cylinders of 15120 * 512 bytes

Device Boot Start End Blocks Id System

/dev/hda1 * 1 3 22648+ 83 Linux

/dev/hda2 556 630 567000 6 FAT16

/dev/hda3 4 12 68040 82 Linux swap

/dev/hda4 649 2584 14636160 f Win95 Ext'd (LBA)

/dev/hda5 1204 2584 10440328+ b Win95 FAT32

/dev/hda6 649 1203 4195737 83 Linux

Tworzenie nowych systemów plików

Najbardziej popularnym poleceniem do zakładania nowego systemu plików jest "mkfs", chociaż na niektórych platformach komenda "newfs" dostarcza bardziej przyjazny interfejs i dopiero wewnątrz wywołuje "mkfs". Typ systemu plików, który chcemy założyć jest przekazywany do "mkfs" jako argument (np. aby utworzyć system plików Veritas należy użyć komendy "mkfs -F vxfs" na większości UNIXowych platform. W Linuxie jednak wygląda to nieco inaczej: "mkfs -t vxfs" ). Powoduje to uruchomienie specjalnej wersji "mkfs'a" dla żądanego systemu plików. Poniżej znajdują się przykłady utworzenia partycji VxFS (Veritas). W pierwszym przykładzie rozmiar partycji został przekazany jako argument, w drugim brak argumentu spowodował wyliczenie przez system maksymalnego dostępnego miejsca.

# mkfs -F vxfs /dev/vx/rdsk/vol1 25g
version 4 layout
52428800 sectors, 6553600 blocks of size 4096, {dokładnie 25GB}
log size 256 blocks unlimited inodes, largefiles not supported
6553600 data blocks, 6552864 free data blocks
200 allocation units of 32768 blocks, 32768 data blocks

# mkfs -F vxfs /dev/vx/rdsk/vol1
version 4 layout
54525952 sectors, 6815744 blocks of size 4096, {dokładnie 26GB}
log size 256 blocks unlimited inodes, largefiles not supported
6815744 data blocks, 6814992 free data blocks
208 allocation units of 32768 blocks, 32768 data blocks

Poniżej znajduje się jeszcze przykład podobnego wywołania, ale dla systemu plików UFS. Zauważmy, że schemat wywołania jest bardzo podobny do poprzedniego, natomiast wypisany wynik działania programu jest znacząco różny.

# mkfs -F ufs /dev/vx/rdsk/vol1 54525952
/dev/vx/rdsk/vol1: 54525952 sectors in 106496 cylinders of
16 tracks, 32 sectors
26624.0MB in 6656 cyl groups (16 c/g, 4.00MB/g, 1920 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 8256, 16480, 24704, 32928, 41152, 49376, 57600, 65824,
74048, 82272, 90496, 98720, 106944, 115168, 123392, 131104,
139328, 147552, 155776, 164000,
...
54419584, 54427808, 54436032, 54444256, 54452480, 54460704,
54468928, 54477152, 54485376, 54493600, 54501824, 54510048,

Czas potrzebny na utworzenie różnych systemów plików może być diametralnie różny. Jest to spowodowane różnicami w rozmieszczeniu plików na dysku. W powyższych przykładach założenie systemu UFS na partycji 25GB zajęło ok.23 minuty, podczas gdy założenie systemu VxFS trwało w przybliżeniu pół sekundy. W kolejnych rozdziałach przedstawimy różne UNIXowe systemy plików i pokażemy powody tak znacznych różnic w samym procesie ich tworzenia.
Do polecenia "mkfs" możemy przekazywać dodatkowe parametry za pomocą opcji -o. Są one przekazywane bezpośrednio do odpowiedniego mkfsa dla danego systemu plików np.:

# mkfs -F vxfs -obsize=8192 /dev/vx/rdsk/myvol
version 4 layout
20971520 sectors, 1310720 blocks of size 8192,
log size 128 blocks
unlimited inodes, largefiles not supported
1310720 data blocks, 1310512 free data blocks
40 allocation units of 32768 blocks, 32768 data blocks

Montowanie i odmontowywanie systemu plików

Główny system plików jest montowany przez jądro systemu podczas jego startu. Każdy inny system plików może zostać zamontowany w dowolnym katalogu głównego systemu plików wyłączając katalog '/'. Punkt montowania to po prostu katalog. Kiedy system plików zostaje zamontowany na danym katalogu jego poprzednia zawartość zostaje ukryta do momentu jego odmontowania jak pokazano na poniższym rysunku.

Montowanie systemu plików /usr
Aby zamontować system plików należy jego typ, urządzenie na którym jest założony oraz punkt montowania podać jako parametry polecenia "mount". w poniższym przykładzie system VxFS został zamontowany w katalogu /mnt1. Samo uruchomienie komendy "mount" bez parametrów wypisuje wszystkie systemy plików aktualnie zamontowane w systemie wraz z ich opcjami montowania:

# mount -F vxfs /dev/vx/dsk/vol1 /mnt1 {dla Linuxa: "mount -t vxfs /dev/vx/dsk/vol1 /mnt1}"
# mount | grep mnt1
/mnt1 on /dev/vx/dsk/vol1 read/write/setuid/delaylog/
nolargefiles/ioerror=mwdisable/dev=1580006
on Tue Jul 3 09:40:27 2002

Tak jak "mkfs" komenda "mount" również posiada swoje odpowiedniki dla każdego systemu plików, które są wywoływane w momencie podania odpowiedniego argumentu.

Gdy system plików jest już zamontowany do tablicy zamontowanych urządzeń dodawane są odpowiednie dane. Tablica ta jest plikiem w katalogu '/etc', który przechowuje wszystkie zamontowane systemy plików, urządzenia na których one się znajdują, ich punkty montowania i listę argumentów, które były podane podczas użycia komendy "mount". Nazwa tej tablicy różni się w zależności od wersji UNIXa. Np. w Systemie V jest to plik 'mnttab', a w linuksie 'mtab'. Poniżej wypisane są przykładowe zawartości tych plików.

# head -6 /etc/mnttab
/proc /proc proc rw,suid,dev=2f80000 995582515
/dev/dsk/c1t0d0s0 / ufs rw,suid,dev=1d80000,largefiles 995582515
fd /dev/fd fd rw,suid,dev=3080000 995582515
/dev/dsk/c1t1d0s0 /space1 ufs ro,largefiles,dev=1d80018 995582760
/dev/dsk/c1t2d0s0 /rootcopy ufs ro,largefiles,dev=1d80010
995582760
/dev/vx/dsk/sysdg/vartmp /var/tmp vxfs rw,tmplog,suid,nolargefiles
995582793

# cat /etc/mtab
/dev/hda6 / ext2 rw 0 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
/dev/hda1 /boot ext2 rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0

Wszystkie wersje Linuxa dostarczają specjalnych funkcji do manipulacji tablicą zamontowanych urządzeń służących do dodawania, usuwania lub czytania wpisów. Są to:

#include
#include
int getmntent(FILE *fp, struct mnttab *mp);
int putmntent(FILE *iop, struct mnttab *mp);

Funkcja getmntent jest używana do odczytywania tablicy, natomiast funkcja putmnttab umożliwia zmianę wpisów. Obie funkcje operują na strukturze mnttab (mtab w Linuxie), która wygląda następująco:

char *mnt_special; /* Urządzenie na którym znajduje się system plików */
char *mnt_mountp; /* Punkt montowania */
char *mnt_fstype; /* Typ systemu plików */
char *mnt_mntopts; /* Opcje montowania */
char *mnt_time; /* Czas montowania */

Samo użycie powyższych funkcji i struktury mnttab jest stosunkowo proste. Szczegóły można znaleźć jak zwykle na stronach manuala.

Aby odmontować system plików wystarczy jako argument polecenia "umount" podać urządzenie lub punkt montowania tak jak na poniższym przykładzie:

# umount /mnt1
# mount | grep mnt1
# mount -F vxfs /dev/vx/dsk/vol1 /mnt1
# mount | grep mnt1
/mnt1 on /dev/vx/dsk/vol1 read/write/setuid/delaylog/ ...
# umount /dev/vx/dsk/vol1
# mount | grep mnt1

Po każdym poprawnym wywołaniu komendy umount odpowiedni wpis zostaje usunięty z tablicy zamontowanych urządzeń.

Automatyczne montowanie

Zazwyczaj po utworzeniu odpowiednich systemów plików sam system zajmuje się ich montowaniem podczas startu. Wirtualna tablica systemów plików (Virtual Filesystem Table) znajdująca się w pliku /stc/vfstab [w Linuxie /etc/fstab] zawiera wszystkie informacje niezbędna do zamontowania poszczególnych systemów plików.
Ten plik jest częściowo tworzony podczas instalacji systemu operacyjnego. Gdy zostaną dodane nowe systemy plików administrator powinien dodać do tego pliku odpowiednie wpisy upewniając się o ich poprawności. Poniżej znajduje się przykładowa zawartość pliku 'fstab' w Linuxie:

# cat /etc/fstab

LABEL=/	/	ext2	defaults	1	1
LABEL=/boot	/boot	ext2	defaults	1	2
/dev/cdrom	/mnt/cdrom	iso9660	noauto,owner,ro	0	0
/dev/fd0	/mnt/floppy	auto	noauto,owner	0	0
none	/proc	proc	defaults	0	0
none	/dev/pts	devpts	gid=5,mode=620	0	0
/dev/hda3	swap	swap	defaults	0	0
/SWAP	swap	swap	defaults	0	0

Pierwsze cztery pola opisują urządzenie, punkt montowania, system plików i argumenty polecenia "mount". Piąte pole jest związane z poleceniem "dump" i informuje który system należy odzyskać z wcześniej utworzonej kopii. Ostatnie pole jest używane przez program "fsck" do ustalenia porządku w jakim poszczególne systemy plików będą sprawdzane podczas bootowania systemu.

Generalnie system operacyjny rozpoczynając działanie zaczyna od podstawowych zadań. Jednym z nich jest zamontowanie głównego systemu plików i to jest zazwyczaj jedyny system plików montowany przed uruchomieniem skryptów systemowych. jako pierwszy proces zostaje uruchomiony program init, który sprawdzając tablicę 'inittab' ustala które polecenia i skrypty są konieczne do dalszego ładowania systemu. Zazwyczaj skrypt który jest odpowiedzialny za automatyczne montowanie znajduje się na pod koniec owej tablicy...

Naprawianie uszkodzonych systemów plików

System plików może znajdować się w jednym z dwóch stanów: czystym (clean) oraz brudnym (dirty). Aby mógł on zostać zamontowany musi być w stanie "czysty", co oznacza strukturalna spójność. Kiedy system plików jest montowany w trybie do odczytu i zapisu jest również zaznaczany jako "brudny" aby zaznaczyć że jest w danej chwili używany. Operacje na systemie plików mogą być niedokończone podczas awarii systemu operacyjnego co może powodować uszkodzenia w strukturze systemu plików. W takiej sytuacje niebezpieczne byłoby montowanie systemu plików bez znajomości rozmiaru uszkodzeń. Dlatego też przywróceniem do stany "czysty" zajmuje się wyspecjalizowany program 'fsck'. Oto przykładowe wywołanie polecenia mount po awarii systemu:

# mount -F vxfs /dev/vx/dsk/vol1 /mnt1
UX:vxfs mount: ERROR: /dev/vx/dsk/vol1 is corrupted. needs checking

System plików jest zaznaczony jako "brudny" co powoduje brak możliwości jego zamontowania. Aby to zmienić należy uruchomić program 'fsck' dla odpowiedniego systemu plików i urządzenia na którym jest zamontowany. Zazwyczaj czynność tą wykonuje za nas system operacyjny podczas ładowania. Dobrym pomysłem jest jednak zapisywanie wyników działania programu 'fsck' na wypadek gdy naprawa się nie uda i potrzebna jest pomoc specjalistów.

2. VERITAS FileSystem (VxFS)

Wstęp

W niniejszej prezentacji zostanie przedstawiony system plików VERITAS w wersji 3.5.
System plików VERITAS jest oparty na bazie ekstentów - ciągłych obszarów pamięci o rozmiarze będącym wielokrotnością rozmiaru bloku. Obsługuje on dyski do 32TB oraz pliki do 2TB. Jest to system plików z tzw. kronikowaniem, ale o tym w dalszej części prezentacji.

Ekstenty

W odróżnieniu od "tradycyjnego" rozmieszczania pliku w blokach o ustalonym rozmiarze, co w przypadku dużych plików prowadzi do konieczności stosowania bloków podwójnie i potrójnie pośrednich, w VxFS plik otrzymuje możliwie duże spójne obszary pamięci, dzięki czemu zarówno odczytywanie, jak i zapis nie wymaga dużych i częstych skoków głowicy dysku do odpowiednich bloków. Zysk jest widoczny również przy odczycie dalszych pozycji w dużych plikach, gdyż nie jest konieczne przechodzenie przez bloki pośrednie, podwójnie oraz potrójnie pośrednie.
Minimalny rozmiar ekstentu to rozmiar bloku dyskowego. Natomiast w przypadku maksymalnej wartości - cały plik może być zapisany w jednym ekstencie.

Strategia przydziału ekstentów

Przy pierwszym zapisie do pliku przydzielony zostaje ekstent o rozmiarze będącym potęgą 2 większą od rozmiaru zapisywanych danych (minimalnie rozmiar bloku). Przy kolejnych zapisach przydzielane są coraz większe spójne obszary pamięci (ich wielkość jest zależna od przyjętej strategii). Gdy zamykamy plik, ostatni przydzielony ekstent jest obcinany, a nie zużyta pamięć zwalniana.
Jeśli przy tworzeniu pliku znamy jego przyszły rozmiar możemy zastosować pre-alokację. Służy do tego polecenie setext:

# > myfile
# setext -e 1024 -r 1024 -f chgsize myfile
# ls -l myfile
-rw-r--r-- 1 root other 1048576 Mar 29 13:36 myfile

Opcja -e wyznacza stały rozmiar ekstentu, który będzie za każdym razem alokowany dla podanego pliku (oczywiście o ile będzie to możliwe). Natomiast opcja -r dokonuje pre-alokacji podanej ilości bloków. Opcja -f wymusza natychmiastowy przydział pamięci.

Błędy wejścia/wyjścia

Pierwotnie w VxFS błędy wejścia/wyjścia nie powodowały załamania systemu plików, a jedynie zaznaczenie odpowiednich struktur jako uszkodzonych i zablokowanie dostępu do nich. Pozostałe struktury były nadal dostępne. Np. podczas odczytu i-węzła VxFS sprawdza jego poprawność i jeśli nastąpi błąd to jest on zaznaczany jako błędny i ustawiana jest flaga konieczności sprawdzenia poprawności systemu plików (poprzez fsck). System może kontynuować pracę z nieuszkodzoną częścią systemu plików.
Obecnie VERITAS FileSystem umożliwia większą swobodę w administrowaniu systemem plików i udostępnia cztery opcje reagowania na błędy wejścia/wyjścia:

disable - po napotkaniu błędu system plików zostanie wyłączony, możliwe będzie bezpieczne odmontowanie i naprawienie przez fsck
nodisable - jest to opcja analogiczna do pierwotnej
wdisable (write disable)- po napotkaniu błędu odczytu będzie możliwa kontynuacja pracy z systemem plików, natomiast wynik błędu zapisu będzie analogiczny do opcji disable
mwdisable (metadata write disable) - jak wyżej, ale jedynie dla zapisu metadanych

Struktura dysku VxFS

Jest 5 wersji struktury dysku dla systemu plików VERITAS. Tutaj zostaną omówione jedynie wersje pierwsza i piąta.

Wersja 1

Struktura dysku VxFS w wersji 1

Struktura dysku w wersji 1 składa się z trzech głównych sekcji poprzedzonych blokiem ładującym (bootstrap):

Superblok - zawiera podstawowe informacje o rozmiarze systemu plików, dostępnym miejscu oraz wskaźniki do pozostałych informacji o strukturze systemu plików. W związku z bezpieczeństwem przechowywanych jest kilka kopii superbloku
Dziennik - służy do zapisywania (kronikowania) wykonywanych operacji na systemie plików w celu szybkiego naprawienia ewentualnych błędów
Jednostki alokacji - obszary tego samego rozmiaru (być może poza ostatnią), które zawierają informacje o wolnych blokach, i-węzłach oraz bloki danych

Ze względu na stały rozmiar Jednostki alokacji ograniczone były możliwości systemu plików VERITAS w tej wersji struktury dysku. Objawiało się to koniecznością ograniczenia liczby i-węzłów przypadających na jedną jednostkę. Także rozmiar ekstentów był ograniczony (musiały się one mieścić w jednej jednostce alokacji).

Wersja 5

Struktura dysku VxFS w wersji 5

Wcześniejsze wersje miały kilka problemów. Do najważniejszych należy stała liczba i-węzłów, która w przypadku małych plików powoduje szybkie ich wyczerpanie przy pozostawionym wolnym miejscu na dysku, natomiast dla dużych plików puste i-węzły niepotrzebnie marnują pamięć. Struktura dysku VxFS w wersji 5 rozwiązuje podane problemy poprzez przechowywanie informacji o strukturze systemu plików w plikach, które mogą rosnąć na żądanie.
Wprowadzone zostało tu pojęcie zbiorów plików (filesets) - termin z rozproszonych systemów plików - każdy zbiór plików wygląda dla użytkownika jak osobny system plików. Przy tworzeniu systemu plików VxFS powstają dwa zbiory plików: podstawowy i strukturalny. Podstawowy zbiór plików zawiera listę i-węzłów wszystkich plików, katalogów itp. Strukturalny zbiór plików zawiera m.in.:

Object location table (Tablica położenia obiektów) - zawiera wskaźniki do struktur potrzebnych przy montowaniu systemu plików
Label file (Plik etykiet) - przechowuje superblok oraz jego repliki
Fileset header file (Plik nagłówkowy zbioru plików) - zawiera opis zbioru plików, m.in. informacje o liczbie przechowywanych i-węzłów, a także numer i-węzła zawierającego listę i-węzłów
Inode list file (Plik listy i-węzłów) - zawiera listę wszystkich i-węzłów znajdujących się w danym zbiorze plików
Inode allocation unit file (Plik jednostki alokacji i-węzłów) - jest wykorzystywany do zarządzania i-węzłami, zawiera bitampę wolnych i-węzłów oraz informacje o dodatkowych operacjach
Log file (Dziennik) - przechowuje wpisy o operacjach na systemie plików
Extent AU state file - przechowuje informacje o alokacji/zużyciu miejsca w jednostkach alokacji
Extent AU summary file - zawiera opis alokacji ekstentów
Free extent map (Mapa wolnych ekstentów) - zawiera mapę wolnych ekstentów

W związku z tym, że informacje o systemie plików są zapisane w plikach system plików musi wiedzieć gdzie są zapisane te pliki. W tym celu używane są różne struktury. Aby zamontować system plików, VxFS potrzebuje odnaleźć katalog główny dla podstawowego systemu plików, co odbywa się w następujący sposób:

Sięgamy do superbloku, który zaczyna się za pierwszymi 8kB dysku
W superbloku mamy zapisany wskaźnik do OLT (object Location Table), która zawiera informacje o numerze i-węzła pliku nagłówkowego zbioru plików, który zawiera informację o wszystkich zbiorach plików
Wybieramy numer i-węzła odpowiadający podstawowemu zbiorowi plików, z którego możemy odczytać informację o wszystkich i-węzłach z tego zbioru plików

Ponieważ wszystkie informacje strukturalne o systemie plików są trzymane w plikach, początkowo inicjowana jest minimalna ilość informacji (np. przy tworzeniu systemu plików alokowane są jedynie 32 i-węzły). W miarę używania systemu plików przechowywane struktury rozrastają się.

Podsumowanie

Główne cechy systemu plików VERITAS to:

Ekstenty jako podstawowa jednostka przydzielanej pamięci
Możliwość przydzielenia ciągłego obszaru pamięci przy tworzeniu pliku
Możliwość kontynuowania pracy z systemem plików po napotkaniu błędu
Struktura dysku (w wersji 5) zapisana w rozszerzalnych plikach, skutkuje bardzo szybkim tworzeniem systemu plików

Niezależnie od pomysłowości twórców systemu plików nie unikniemy nigdy fragmentacji. Także i w tym przypadku po dłuższym czasie używania VxFS pozostaną jedynie małe obszary spójnej pamięci, co niweluje wszystkie korzyści z wprowadzenia ekstentów. W tym przypadku pozostaje nam jedynie skorzystać z programu do defragmentacji (np. opcja reorganizacji ekstentów w pakiecie fsadm).

3. UFS (Unix File System)

System ten jest znany również pod nazwą FFS (Fast File System). Był to jeden z najszerzej studiowanych Unixowych systemów plików, a decyzje podjęte przy jego projektowaniu mają swoje odzwierciedlenie w kolejnych systemach włączając w to najbardziej popularne, czyli ext2 i ext3.

Historia UFSa

Problemy ze starym, 512 bajtowym systemem plików pojawiły się wraz z coraz szybszym rozwojem systemu Unix. Motywacja do stworzenia nowego, szybkiego systemu plików była bardzo niska wydajność aplikacji tworzonych dla Unixa. Dotychczasowy system plików nie był w stanie sprostać zwiększonemu zapotrzebowaniu na przepustowość częściowo z powodu wspomnianych 512-kilobajtowych bloków porozrzucanych na dysku. Innymi przyczynami słabej wydajności były:

małe bloki powodowały bardzo szybką fragmentację większych plików co zwiększenie operacji we/wy potrzebnych do uzyskania dostępu do pliku
i-węzły i dany były fizycznie rozdzielone na dysku co mogło powodować duże straty czasu. Przykładowo 150MB system plików posiadał 4MB i-węzłów poprzedzonych 146MB danych. Teraz aby uzyskać dostęp do pliku następowało długie wyszukiwanie poprzedzone odczytem odpowiedniego i-węzła. Czas ten powiększało dodatkowo opóźnienie spowodowane ruchem głowicy z jednego bloku do kolejnego, który z dużym prawdopodobieństwem nie był fizycznie kolejnym blokiem

Bazując na powyższych faktach zespół z Berkelay postanowił zaprojektować nowy system plików, który miał znacznie zmniejszyć czas dostępu do plików oraz liczbę operacji we/wy, a także zwiększyć wydajność dysku.
Ważnym aspektem nowego projektu były warstwy danych na dysku. Nowy system plików został podzielony na kilka cylindrów, które odnosiły się bezpośrednio do cylindrycznego ułożenia danych na dysku (należy pamiętać, że na starszych dyskach każdy cylinder miał taka samą pojemność bez względu na zewnętrzne czy wewnętrzne położenie). Każdy cylinder zawierał:

kopie superbloku
stałą liczbę i-węzłów
mapę bitową opisującą wolne i-węzły i bloki danych
tabelę opisującą użycie bloku danych
właściwe bloki danych

Stała liczba węzłów dla cylindra była wyliczana tak, aby każdy i-węzeł odpowiadał 2048 bajtom danych.
Aby osiągnąć pewien poziom integralności meta-dane cylindrów nie były przechowywane na tym samym talerzu. Zamiast tego, aby nie dopuścić do przechowywania strukturalnych danych systemu plików na jednym talerzu meta-dane z drugiego cylindra były umieszczone na drugim talerzu, meta-dane z trzeciego na trzecim itd. Z wyjątkiem pierwszego cylindra dane były przechowywane przed oraz po meta-danych.

Schemat systemu plików UFS

Bloki i fragmenty

FFS dopuszczał rozmiar bloków nie mniejszych niż 4096 bajty. Liczba ta została wybrana tak, aby pliki aż do 4GB były dostępne niebezpośrednio najwyżej w dwóch poziomach. Rozmiar bloku wybierało się podczas tworzenia systemu plików i nie mógł być dynamicznie zmieniany. Oczywiście różne systemy plików mogły posiadać inne rozmiary bloków.
Ponieważ w czasach gdy opracowano FFS większość plików była mniejsza niż 4096 bajtów mogły one być przechowywane w pojedynczym bloku. Jeżeli plik był zaledwie trochę większy niż wielokrotność rozmiaru bloku mogło to owocować dużym marnotrawstwem przestrzeni dyskowej. Aby temu zapobiec nowy system plików przedstawiał koncepcję fragmentów. Zgodnie z nią bloki danych mogły zostać podzielone na 2, 4 lub 8 fragmentów, których rozmiary zostają ustalone przy tworzeniu systemu plików.. jeżeli więc plik miał rozmiar 4100 bajtów zawierałby jeden blok 4096-bajtowy oraz fragment 1024-bajtowy przechowujący pozostałą część danych. W przypadku powiększenia pliku alokowany był nowy fragment lub blok. Algorytm alokacji wyglądał następująco:

Jeżeli jest wolne miejsce w fragmencie lub bloku wystarczające na zapisanie pliku nowe dane są po prostu kopiowane do tego bloku lub fragmentu
Jeżeli nie ma fragmentów, a istniejący blok jest pełny alokowane są nowe bloki i wypełniane do momentu zakończenia zapisu lub gdy zabraknie danych do wypełnienia kolejnego bloku. w tym wypadku albo zostanie zaalokowany blok podzielony na fragmenty albo cały zależnie od potrzeby
Jeżeli plik zawiera jeden lub więcej fragmentów i ilość nowych danych razem z danymi w fragmentach przekracza pojemność bloku tworzony jest nowy blok poprzedzony nowymi danymi doklejonymi do pliku. Dalej sytuacja sprowadza się do przedstawionej powyżej [pełny blok].

Oczywiście rozszerzanie plików o niewielkie ilości danych spowoduje nadmierne kopiowanie ponieważ fragmenty będą alokowane i dealokowane oraz kopiowane do właściwych bloków.
Ilość zaoszczędzonej w ten sposób przestrzeni jest zależna od rozmiaru bloków i fragmentów. Ponieważ z 4096-bajtowymi blokami i 512-bajtowymi fragmentami ilość utraconej przestrzeni jest mniej więcej taka sama jak przy poprzednim systemie plików lepsza wydajność nie jest osiągana kosztem traconej przestrzeni.

Algorytm alokacji FFS

Grupa z Berkley zauważyła że postęp w dziedzinie technologii produkcji dysków twardych powoduje pojawienie się w jednym komputerze dysków o różnych parametrach. Aby wyrównać różnice wydajności i należycie wykorzystać prędkość procesora system plików był dostosowywany do konkretnego sprzętu i systemu operacyjnego.
To zaowocowało następującym algorytmem alokacji:

bloki danych dla pliku są alokowane w obrębie tego samego cylindra jeżeli to możliwe. W miarę możliwość położenie bloków było poprawiane rotacyjnie tak, aby podczas odczyt pliku sekwencyjnie odbywał się możliwie najszybciej.
powiązane informacje są połączone razem jeżeli to możliwe. [np.: i-węzły katalogu i jego pliki znajdują się w jednym cylindrze - z tego powodu i-węzły katalogów są alokowane w cylindrach o największej wolnej liczbie i-węzłów i najmniejszej liczbie już znajdujących się tam katalogów ]
dane pliku są umieszczane w tym samym cylindrze co jego i-węzeł [pozwala to zminimalizować ruch głowicy podczas odczytu i-węzła pliku i jego danych]
duże pliki są alokowane w rożnych cylindrach aby uniknąć pochłonięcia zbyt dużej części cylindra przez jeden plik.

Aby powyższe strategie przydziału bloków działały potrzeba pewnej ilości wolnej przestrzeni. Eksperymenty pokazały, że schemat ten działa dobrze gdy było dostępne przynajmniej 10% wolnej przestrzeni na dysku. Gdy próg ten został przekroczony tylko administrator mógł alokować dodatkową pamięć. Prowadziło to niestety do marnotrawienia stałej ilości pamięci.

Analiza wydajnościowa

Przeprowadzono wiele testów aby sprawdzić efektywność nowego systemu plików. Oto kilka wniosków:

warstwowa polityka i-węzłów okazała się efektywna. Wywołując komendę 'ls' w dużym katalogu liczba dostępów do dysku spadła dwukrotnie jeżeli katalog zawierał inne katalogi i nawet ośmiokrotnie gdy zawierał tylko pliki
wydajność systemu plików poprawiła się kolosalnie. Stary system plików był w stanie wykorzystać tylko 3 do 5 procent przepustowości dysku podczas gdy FFS potrafił wykorzystać nawet 47%
zarówno odczyt jak i zapis odbywały się szybciej, głównie dzięki zwiększonym blokom. One też spowodowały przyspieszenie alokacji.

Te rezultaty nie do końca są dobrą reprezentacją sytuacji na świecie i FFS może również zawodzić gdy w czasie zwiększa się fragmentacja. To jest jednak zazwyczaj prawdą gdy system plików osiągnie ok. 90% dostępnej przestrzeni. Jest to jednak prawdziwe dla wszystkich innych typów systemów plików.

Dodatkowe cechy UFSa

W systemie tym zaimplementowano również wiele nowych możliwości. Dzisiaj są one przyjęte jako nieodzowne i znajdują się w każdej implementacji systemu plików. Były to m.in.:

linki symboliczne (tylko twarde)
długie nazwy plików (255 znaków zamiast 15)
zamki dzielone i wyłączne na plikach
zmiana nazwy pliku [wcześniej też była możliwa, ale poprzez wywołanie kilku funkcji systemowych]
quoty użytkownika

Co się zmieniło od pierwszych wersji UFSa?

Zmiany w technologii wytwarzania dysków twardych spowodowały niemożność używania stałego rozmiaru dla cylindrów. Poza tym ścieżki znajdujące się na zewnętrznych częściach talerza potrafią gromadzić dużo więcej informacji niż te wewnętrzne. To wszystko powoduje, że dzisiaj pojęcie cylindra jako wspomnianego powyżej nie może mieć miejsca. W ten sposób niektóre z optymalizacji wczesnych implementacji UFSa nie nadają się do dzisiejszych dysków twardych i mogłyby w określonych okolicznościach wyrządzić więcej szkody niż dobrego.

4. Ext3 FileSystem

Jak do tego doszło ...

Pierwotnie w Linuksie używany był Minix filesystem zapożyczony (a właściwie odziedziczony) z systemu Minix, pod którym powstawał pierwszy Linux. System plików Minix przechowywał adresy bloków będące liczbami 16-bitowymi i nie posiadał bloków potrójnie pośrednich, co ograniczało wielkość systemu plików do 64MB (dla bloków 1kB). Wpisy do katalogów były stałej długości, przez co nazwy plików były ograniczone do 14 znaków. Stała była także liczba i-węzłów.

W 1992 roku Minix został zastąpiony przez ext filesystem, który obsługiwał dyski do 2GB i pozwalał na nazwy plików długości nie większej niż 255 znaków. Niestety był to system plików nadal bardzo daleki od ideału. Szczególnie nieefektywnie były zarządzane wolne bloki pamięci oraz i-węzły, co objawiało się silną fragmentacją ...

Ext2 FileSystem

Ograniczenia poprzednich systemów plików spowodowały konieczność wprowadzenia zmian i ulepszeń. Wynikiem tego było powstanie w 1994 roku systemu plików ext2, który obsługuje dyski do 4TB.
Następujące zmiany wpłynęły na efektywność systemu plików Ext2:

Możliwość ustalenia przez administratora rozmiaru bloku (1024, 2048 lub 4096B)
Możliwość ustawienia liczby i-węzłów, zgodnie z potrzebami
Podział bloków dyskowych na grupy, każda grupa zawiera bloki z sąsiadujących ścieżek
Pre-alokacja bloków dyskowych dla zwykłych plików, co redukuje fragmentację
Szybkie linki symboliczne - dla linków poniżej 60 bajtów całość jest przechowywana w i-węźle

Struktura dysku Ext2

Struktura dysku Ext2

Pierwszy blok dysku nie jest używany przez system plików Ext2 (jest on przeznaczony na program ładujący, ang. boot loader). Reszta jest podzielona na grupy bloków, z których każda zawiera:

kopię superbloku systemu plików
kopię deskryptorów grup
bitmapę bloków danych
bitmapę i-węzłów
tabelę i-węzłów
bloki danych

Tylko superblok grupy 0 jest używany przez system, pozostałe nie są zmienione do czasu ponownego uruchomienia systemu (a właściwie uruchomienia programu e2fsck), kiedy to superblok z grupy 0 jest kopiowany do pozostałych grup, chyba że dane w nim są niespójne i wymagają naprawy. Wtedy program e2fsck może skorzystać z superbloku innej grupy do odtworzenia oryginalnego.
Superblok zawiera najważniejsze informacje o systemie plików, konieczne do jego zamontowania, m.in.:

Liczbę i-węzłów
Liczbę bloków w systemie plików
Liczbę zarezerwowanych bloków
Liczbę wolnych bloków
Liczbę wolnych i-węzłów
Rozmiar bloku
Liczbę bloków w grupie
Liczbę i-węzłów w grupie

... i wiele innych. Wszystkie te pola znajdują się w strukturze ext2_super_blok.

Deskryptor grupy opisuje bloki znajdujące się w danej grupie, w szczególności zawiera:

Numer bloku zawierającego bitmapę bloków
Numer bloku zawierającego bitmapę i-węzłów
Numer pierwszego bloku tablicy i-węzłów
Liczbę wolnych bloków w grupie
Liczbę wolnych i-węzłów w grupie
Liczbę katalogów w grupie

Tablica i-węzłów zawiera struktury kolejnych i-węzłów, z których każda ma 128 bajtów, co daje 32 i-węzły na blok rozmiaru 4KB.

Po więcej szczegółów odsyłamy do wykładu :)

Koncepcja

System plików Ext3 był tworzony w oparciu o dwa pomysły:

Miał być systemem plików z kronikowaniem (journaling file system)
Powinien być jak najbardziej kompatybilny z systemem Ext2

Można powiedzieć, że cele te zostały osiągnięte. Oba systemy zgadzają się na poziomie struktur, tak że możliwe jest montowanie jednego systemu plików jako drugiego (z dokładnością do tworzenia dziennika).

Kronikowanie

Kronikowanie jest pomysłem na złagodzenie skutków błędów spowodowanych przez załamanie się systemu w trakcie wykonywania operacji zapisu. Do tej pory takie błędy powodowały konieczność uruchomienia specjalnego programu, który przywracał spójność danych. Było to jednak bardzo powolne, gdyż wymagało przejrzenia całego dysku. Ideą kronikowania jest zastąpienie tego przez możliwość sprawdzenia jedynie ostatnich operacji zapisu odnotowanych w specjalnym dzienniku. Kronikowanie jest w pewnym sensie odpowiednikiem transakcji w bazach danych, tzn. albo cała operacja zapisu powiedzie się, albo w całości zostanie cofnięta.

Ext3 jako system plików z kronikowaniem

Zmiany dokonywane w systemie plików Ext3 są podzielone na trzy części:

Najpierw kopie bloków do zapisania wraz z informacją o zapisie są zapamiętywane w dzienniku
Kiedy zapis do dziennika jest zakończony, bloki są zapisywane na dysk
Po zakończeniu zapisu zapamiętane bloki danych zostają usunięte

Podczas odtwarzania spójności systemu plików program e2fsck rozróżnia dwa przypadki:

Załamanie systemu nastąpiło przed zakończeniem zapisywania operacji do dziennika - w dzienniku jest niekompletny wpis, ale struktury systemu plików pozostają niezmienione, wtedy e2fsck zignoruje wpis
Załamanie systemu nastąpiło po wpisaniu operacji do dziennika - zapisane bloki są kompletne i e2fsck zapisuje je na dysk, a tym samym przywraca spójność danych

Nie oczekujmy jednak zbyt wiele od takiego systemu plików. Czasami odzyskanie utraconych danych nie jest możliwe. Zadaniem kronikowania jest odtworzenie spójności systemu plików, a nie jego zawartości. Poza tym kronikowanie odbywa się jedynie na poziomie wywołań systemowych (system calls).

Metadane

Ponadto zazwyczaj systemy plików z kronikowaniem nie kopiują do dziennika wszystkich bloków danych, a jedynie bloki zawierające tzw. metadane. W systemach plików Ext2 i Ext3 wyróżniamy sześć rodzajów metadanych:

superbloki
deskryptory grup
i-węzły
bloki do adresowania pośredniego
bitmapy bloków danych
bitmapy i-węzłów

Większość systemów plików z kronikowaniem, takich jak: ReiserFS, XFS i JFS ograniczają się do zapisywania w dzienniku informacji o zmianach jedynie w metadanych. Jest to wystarczające do odzyskania spójności systemu plików, ale nie zapobiega utracie (niekiedy ważnych) informacji.

System plików Ext3 można skonfigurować tak aby zapamiętywał zarówno metadane jak i zwykłe dane. Ext3 pozwala administratorowi na wybór spośród trzech trybów kronikowania:

Journal - wszystkie dane oraz metadane zostaną zapisane do dziennika. Zmniejsza to szanse na utratę danych, jednak zwiększa liczbę koniecznych odwołań do dysku. Jest to jednocześnie najbezpieczniejsza i najwolniejsza opcja.
Ordered - tylko bloki metadanych są kopiowane do dziennika, ale system plików grupuje metadane i odpowiadające im bloki danych tak, aby dane zostały zapisane na dysk przed metadanymi. Zmniejsza to szanse na błędy wewnątrz plików. Jest to domyślny tryb dla Ext3
Writeback - tylko bloki metadanych są zapisywane do dziennika, jest to najczęściej spotykana opcja w systemach plików z kronikowaniem, jest przy tym najszybsza

JBD (Journaling Block Device)

Zazwyczaj dziennik systemu plików Ext3 jest przechowywany w ukrytym pliku .journal położonym w katalogu głównym systemu plików.
System plików Ext3 nie zarządza dziennikiem we własnym zakresie, ale korzysta z wbudowanego w jądro interfejs do obsługi dzienników zwanego Journaling Block Device Należy pamiętać, że JBD korzysta z tego samego urządzenia co Ext3, zatem jest tak samo podatny na załamania systemu i musi się przed nimi zabezpieczyć.
Współpraca między systemem plików Ext3, a JBD opiera się na trzech podstawowych jednostkach:

Rekord dziennika (Log record) - opisuje pojedynczy wpis do dziennika (pojedynczą zmianę w systemie plików)
Atomowa operacja (Atomic operation) - składa się z rekordów dziennika dotyczących tego samego wywołania systemowego
Transakcja (Transaction) - zawiera kilka atomowych operacji, których rekordy są zaznaczone jako poprawne dla programu e2fsck w tym samym czasie

Rekord dziennika

Jest to opis niskopoziomowej operacji, która ma zostać wykonana na systemie plików. JBD zapisuje w tym rekordzie całe zmieniane bloki, a nie pojedyncze bajty, co może powodować marnowanie pamięci, ale bardzo upraszcza wszystkie operacje. Rekordy są reprezentowane wewnątrz dziennika jako normalne bloki danych (lub metadanych) z dopisaną informacją typu journal_block_tag_t, w której przechowywana jest informacja o numerze bloku w systemie plików oraz flagi.

Atomowe operacje

Opisują stan dziennika związany z pojedynczym wywołaniem systemowym, które zwykle jest podzielone na kilka operacji niskopoziomowych, z których każdej będzie odpowiadał jeden rekord dziennika. Aby zapobiec niespójności danych, system plików Ext3 musi zapewnić niepodzielność każdego wywołania systemowego. W trakcie naprawy systemu po awarii albo cała operacja jest wykonana albo wszystkie jej części zostają cofnięte.

Transakcje

Ze względów wydajnościowych interfejs JBD grupuje rekordy dziennika, które należą do kilku operacji atomowych w jedną transakcję. Wszystkie rekordy dotyczące jednej operacji muszą być w tej samej transakcji. Wszystkie rekordy jednej transakcji są przechowywane w kolejnych blokach dziennika. Interfejs JBD traktuje pojedynczą transakcję jako całość (np. bloki używane przez transakcję są zwalniane dopiero wówczas, gdy wszystkie rekordy dziennika są zatwierdzone w systemie plików).
Każda transakcja jest opisana w strukturze transaction_t. Jej najważniejszym polem jest s_state, które opisuje aktualny stan transakcji. Transakcja może być:

Zakończona - wszystkie rekordy w transakcji zostały fizycznie zapisane do dziennika. Podczas naprawiania systemu plików program e2fsck rozważa wszystkie zakończone transakcje i zapisuje odpowiednie bloki na dysk. W tym przypadku pole s_state zawiera wartość T_FINISHED
Nie zakończona - co najmniej jeden rekord transakcji nie został fizycznie zapisany do dziennika lub nowe rekordy są nadal dodawane do transakcji. Podczas naprawy systemu plików program e2fsck pominie taką transakcję. Możliwe wartości pola s_state to:
- T_RUNNING - transakcja nadal przyjmuje nowe operacje atomowe
- T_LOCKED - transakcja nie przyjmuje już nowych operacji, ale niektóre nie są jeszcze zakończone
- T_FLUSH - wszystkie operacje atomowe są zakończone, ale jakieś rekordy nie są jeszcze zapisane do dziennika

Zakończona transakcja zostaje usunięta z dziennika jedynie wtedy, gdy interfejs JBD stwierdzi, że wszystkie bloki danych opisywane przez rekordy w danej transakcji zostały fizycznie zapisane do systemu plików Ext3.

Podsumowanie

System plików Ext3 powstał poprzez połączenie systemu plików Ext2 i kronikowania.
Jest on w pełni zgodny z systemem plików Ext2, co umożliwia podmianę obydwu systemów plików.
Dziennik jest w dużej mierze niezależny od systemu plików Ext3, jego obsługę zapewnia interfejs JBD
Dodatkowo w Ext3 zostały wprowadzone indeksowane katalogi (zastąpiono reprezentację listową na drzewiastą), co znacznie przyśpieszyło wydajność systemu.

5. ReiserFS

Wstęp

Większość systemów plików w Linuksie opera się na wcześniej istniejących systemach plików. Reiserfs został stworzony zupełnie od zera. Autorem systemu jest Hans Reiser z firmy Namesys. Brak oparcia w istniejącym systemie plików niesie za sobą pewne koszty takie jak problemy ze stabilnością systemu, który dopiero jest rozwijany. Obecna wersja systemu jest w pełni stabilna.

Twórca Hans Reiser jest zwolennikiem unifikowania nazw (i nazwanych obiektów) w jedną przestrzeń. W swoim systemie dążył do stworzenia jak najbardziej jednolitego interfejsu dostępu do różnych obiektów (takich jak katalogi, pliki, dane). To podejście doprowadziło go do rozwiązania, w którym wszystkie dane na dysku (zarówno metadane katalogów i plików jak i same dane użytkownika) są przechowywane w jednej globalnej dużej strukturze danych. Jest nią słownik zaimplementowany na B+drzewach. Pokrótce omówię tutaj wersję 3 tego systemu plików.

Podstawowe cechy

Podstawowym założeniem przy tworzeniu pierwszej wersji było stworzenie działającego i możliwie prostego systemu, a następnie rozszerzanie go o kolejne cechy. W chwili obecnej Reiserfs posiada następujące możliwości:

Bardzo dobra wydajność dla małych plików
Dobra wydajność, również przy operacjach na katalogach z dużą liczbą plików dzięki zastosowaniu drzew zrównoważonych
Alternatywne podejście do obsługi małych plików. W innych systemach było to z reguły realizowane przez nakładkę na system działającą na zasadzie bazy danych, tutaj mechanizm obsługi małych plików jest wbudowany w system, dzięki temu oszczędzamy około 6% miejsca
Małe pliki (do 3984 bajtów, przy blokach wielkości 4kB) są trzymane bezpośrednio w drzewie
Dane nie są przetrzymywane w blokach stałej wielkości, aby nie marnować miejsca na dysku i zwiększyć wydajność
Szybki mechanizm księgowania (księgowanie meta-danych)

B+drzewa

B+drzewa użyte w systemie ReiserFS różnią się od tradycyjnych B-drzew brakiem danych w węzłach wewnętrznych. Dane są umieszczane wyłącznie w liściach lub specjalnych węzłach umieszczonych poniżej poziomu liści, służących do obsługi dużych plików. Takie podejście umożliwia użycie miejsca w węzłach na dodatkowe klucze i wskaźniki, a w rezultacie na zwiększenie stopnia rozgałęzienia drzewa.

Typy węzłów

Istnieją trzy typy węzłów:

Węzły wewnętrzne
Nie zawierają danych lecz jedynie wskaźniki do węzłów o poziom niżej poprzedzielane kluczami. Klucz poprzedzający wskaźnik jest jednocześnie równy pierwszemu kluczowi z poddrzewa, do którego odnosi się ten wskaźnik. Dla układu (key1, ptr, key2) wszystkie elementy w poddrzewie wskazywanym przez ptr mają klucze z przedziału [key1,key2).
Węzły sformatowane
Zawierają wpisy. W ReiserFs wyróżniamy cztery rodzaje wpisów - dane bezpośrednie, dane pośrednie, wpisy katalogowe i wpisy informacyjne. Każdy wpis w węźle sformatowanym zawiera swój klucz. Węzły sformatowane są bądź liśćmi bądź mają do siebie podczepione jeszcze liście niesformatowane. Każdy wpis w węźle sformatowanym ma swój nagłówek oraz dane.
Liście niesformatowane
Nie mają żadnej struktury - służą do przechowywania ciągu bajtów. W liściach niesformatowanych nie ma kluczy. Długość ścieżki do liścia niesformatowanego jest zawsze o jeden dłuższa niż długość ścieżki do węzła sformatowanego (jest to błąd projektowy powodujący spadek wydajności i w wersji Reiser4 zostanie on poprawiony)

Wpisy w węzłach sformatowanych

Możliwe typy wpisów w węzłach sformatowanych to:

Dane bezpośrednie
Zawierają ogony plików. Końcówki kilku plików (czyli długość pliku modulo wielkość bloku) nie zajmują całego bloku dyskowego, wiec można zaoszczędzić miejsce upychając je razem do jednego bloku, uzyskując w ten sposób około 6% więcej miejsca. Jest to szczególnie ważne w przypadku przechowywania na dysku bardzo wielu małych plików. Z drugiej strony, obsługa ogonów niesie ze sobą pewne problemy. Jeśli dopisujemy dane na końcu pliku, to system musi przenosić ogon do innego bloku lub rozbijać ogon na dwa bloki. Możemy wyłączyć mechanizm upychania ogonów, co zwiększy wydajność systemu kosztem większego marnowania miejsca.
Dane pośrednie
Przechowują wskaźniki do liści niesformatowanych. W liściach niesformatowanych przechowywane są pozostałe (oprócz ogonów) dane plików.
Wpisy katalogowe
Zawierają klucz pierwszej pozycji w katalogu, oraz kolejne pozycje. Pozycja zawiera identyfikator obiektu oraz jego nazwę. Pozycje posortowane są zgodnie z czterema pierwszymi literami nazwy.
Wpisy informacyjne
Zawierają informacje o uprawnieniach, wielkości, czasie modyfikacji i utworzenia. Istnieje możliwość aby te dane były przechowywane nie jako osobne wpisy, ale razem z wpisami katalogowymi.

Odnajdywanie danych w drzewie

Jak łatwo się domyśleć obiekty systemu plików takie jak katalogi i pliki mogą być bardzo duże i zajmować więcej niż jeden węzeł w drzewie. Aby można było je odnaleźć w drzewie każdy taki obiekt ma przyporządkowany identyfikator, który jest liczbą 32 bitową.

Można myśleć o tym identyfikatorze jak o numerze inoda w przypadku systemu Ext2. W skład tego identyfikatora wchodzą następujące pola:

k_dir_id - Identyfikator katalogu nadrzędnego
k_object_id - Identyfikator obiektu (pliku/katalogu) którego dotyczy klucz
k_offset - Pozycja w obiekcie której dotyczy ten wpis. W przypadku plików jest to pozycja w bajtach. W przypadku katalogów cztery pierwsze litery pierwszej pozycji która znajduje się w tym wpisie.
k_uniqness - Stała wartość zależna od typu wpisu.

Struktura klucza gwarantuje, że węzły należące do tego samego pliku/katalogu będą obok siebie w porządku drzewiastym co umożliwi ich odnalezienie. Dodatkowo dzięki polu k_dir_id pliki i podkatalogi należące do jednego katalogu będą leżały blisko siebie w porządku drzewiastym.

Podsumowanie

Autor ReiserFS chciał aby system był bardzo wydajny dla małych plików, gdyż jak wynika z badań, większość operacji około 80% odbywa się na plikach mniejszych niż 10KB. Niewątpliwie udało mu się to osiągnąć. System ten jest nieporównywalnie lepszy od innych w tym zakresie. Jednocześnie przy operacjach dla dużych plików ma porównywalną wydajność jak inne systemy plików. Mechanizm księgowania daje możliwość stosowania go dla serwerów, bo wznawianie systemu po awarii nie będzie trwało zbyt długo.

Także, w ciągłej fazie rozwoju jest wersja Reiser4, która ma przynieść następujące istotne zmiany:

Przechowywanie danych w przedziałach (extents)
Zwiększona modularność dzięki wtyczkom (plugins)
Listy uprawnień (ACL)

6. Pseudo Filesystems (na przykładzie procfs)

Wstęp

System plików jest zazwyczaj postrzegany jako hierarchia plików i katalogów zapisanych gdzieś na dysku. Jest jednak kilka typów systemów plików, które nie przechowują udostępnianych informacji na zewnętrznym nośniku. Do najważniejszych należą procfs (opis procesów), specfs (reprezentuje urządzenia jako pliki) oraz tzw. RAM-disk, czyli systemy plików zapisywane w pamięci RAM (są one bardzo szybkie, ale niestety nietrwałe). W tej prezentacji idea pseudo-systemu plików zostanie omówiona na przykładzie procfs.

System plików /proc (procfs)

System plików /proc został po raz pierwszy zaprezentowany w 1984 roku w ósmej wersji Unix'a. Procfs powstawał z myślą o zastąpieniu wywołania systemowego ptrace(), służącego głównie do debug'owania, tak aby cała przestrzeń procesu była widoczna i modyfikowalna za pomocą operacji read oraz write. Ponadto procfs miał za zadanie udostępniać użytkownikowi wszelkie istotne informacje o procesie.

Nazwa bierze się od katalogu /proc, w którym zazwyczaj montowany jest ten system plików. Pierwotnie procfs miał płaską hierarchię i zawierał jedynie pliki o nazwach będących pid'ami procesów (po jednym dla każdego procesu w systemie). Każdy taki plik reprezentował całą pamięć zajmowaną przez dany proces, rozmiar pliku mówił o wielkości tej pamięci.

W kolejnych wersjach zamieniono płaską hierarchię na bardziej rozbudowaną, drzewiastą (tą którą znamy dzisiaj). W katalogu /proc znajdują się ogólne informacje o systemie oraz katalogi o nazwach będących numerami pid'ów procesów, które opisują. W każdym takim katalogu znajduje się informacja o danym procesie (która znowu może być podzielona na katalogi), np. przestrzeń adresowa procesu, jego status, czy otwarte deskryptory itp.

W Linuksie system ten został zaimplementowany w ramach VFS (wirtualnego systemu plików), dzięki czemu dostęp do katalogu /proc odbywa się na takich samych zasadach, jak do innych systemów plików (z uwzględnieniem praw odczytu/zapisu).

Konstrukcja

Ze względu na to, że system plików /proc nie zapisuje żadnych danych na dysku, nie wymaga on alokacji bloków. Wszelkie informacje przechowywane przez procfs są trzymane w pamięci, w strukturze proc_dir_entry. Zawartość plików jest tworzona dynamicznie, na żądanie.

Superblok systemu plików /proc nie jest nigdzie zapisany, jego struktury są ustawiane statycznie podczas operacji montowania. Przydzielany jest też wtedy i-węzeł dla katalogu głównego, ustawiane są jego operacje (struktura proc_root_inode_operations). Struktura proc_dir_entry dla katalogu głównego również jest tworzona statycznie.

Numery i-węzłów plików są przydzielone statycznie, lub są wyliczane na podstawie numeru pid opisywanego procesu i rodzaju pliku. Większość plików udostępnia jedynie funkcję odczytu, ale są i takie, do których można pisać.

Struktura proc_dir_entry

Ze względu na drzewiastą strukturę katalogu /proc, także struktura proc_dir_entry tworzy drzewo. Odpowiedzialne są za to pola:

next - wskaźnik na następny katalog
parent - wskaźnik do katalogu nadrzędnego
subdir - wskaźnik na pierwszy z podkatalogów

Pozostałe pola struktury (ważniejsze) to:

name - nazwa węzła
namelen - długość nazwy
mode - atrybuty pliku/katalogu
uid i gid - numery właściciela i grupy pliku
size - rozmiar pliku
proc_fops - wskaźnik do struktury file_operations opisującej operacje na pliku
proc_iops - struktura opisująca operacje na i-węźle
read_proc i write_proc - funkcje do pisania i czytania pliku
count - licznik odwołań do pliku

Zawartość katalogu /proc

Informacja przechowywana w katalogu /proc jest bardzo rozległa i powiększa się z każdą kolejną wersją jądra Linuksa. Niektóre z dostępnych plików to:

W katalogu /proc:

cpuinfo - informacje o procesorze
devices - lista dostępnych urządzeń znakowych i blokowych
filesystems - lista systemów plików obsługiwanych przez jądro
ioports - lista portów urządzeń wejścia/wyjścia
ksyms - tablica symboli eksportowanych jądra
meminfo - informacje o pamięci operacyjnej i pamięci swap
modules - informacje o załadowanych modułach
mounts - lista zamontowanych systemów plików
version - wersja jądra z którym pracujemy

W katalogu /proc/[pid]:

exe - dowiązanie do kodu procesu
mem - cała pamięć procesu (pisząc do tego pliku możemy zmieniać jego dane)
status - informacje o procesie
fd - katalog z dowiązaniami do otwartych plików procesu

Podsumowanie

Informacje udostępniane przez system plików /proc są używane przez wiele różnych programów. Do najważniejszych należy używany bardzo często program ps, który przegląda wszystkie katalogi opisujące procesy i wypisuje interesujące nas informacje. Z katalogu /proc korzystają również niektóre programy do debug'owania, a także program top.
Należy pamiętać, że niektóre z programów zakładają istnienie tego systemu plików właśnie w katalogu /proc, zatem najlepiej jest go montować właśnie tam.

Więcej informacji o systemie procfs, tworzeniu nowych plików/katalogów w /proc, jak i samej strukturze proc_dir_entry można znaleźć w scenariuszach laboratoryjnych, a także katalogu [źródła jądra]/fs/proc oraz pliku proc_fs.h.

7. Rozproszone systemy plików (na przykładzie NFS)

Wraz ze wzrostem popularności sieci komputerowych, które pojawiły się w latach 70-tych, a szerzej rozprzestrzeniły w latach 80-tych, pojawiła się potrzeba dzielenia plików pomiędzy różnymi maszynami. Początkowo używano Unixowych narzędzi takich jak uucp i ftp do przenoszenia plików z jednego komputera do drugiego. Ponieważ dyski ciągle były dość drogie powodowało to dostęp do plików poprzez sieć bez użycia lokalnej pamięci.
W 1980-tych latach powstało wiele różnych rozproszonych systemów plików włączając w to:

Network Filesystem (NFS)
Remote File Sharing (RFS)
Andrew File System (AFS)
Distributed File Service (DFS)

W przeciwieństwie do lokalnych systemów plików, gdzie pamięć jest fizycznie umiejscowiona i dostępna tylko dla procesów działających na tej samej maszynie, systemy rozproszone używają architektury klient/serwer, gdzie jeden serwer z systemem plików może udostępniać pliki wielu klientom. Istotny jest przy tym fakt, że zachowywane są wszelkie własności plików takie jak prawa dostępu czy nazwa właściciela, a przy tym cała architektura jest dla użytkownika całkowicie niewidoczna.
Przez ostatnie 30 lat pojawiało się wiele rozproszonych systemów plików. Wiele szybko zakończyło swój żywot. Zdecydowanie największe sukcesy na tym polu odniósł Network Filesystem (NFS), który pojawił się w połowie lat osiemdziesiątych. Pomimo braku bogactwa cech, które udostępniały inne systemy plików jak np. DCE (Distributed File Service), prostota samego protokołu oraz fakt iż był on publicznie dostępny zaowocowała przeniesieniem go do wielu systemów operacyjnych. Poniższy rozdział opisuje rozproszone systemy plików ze szczególnym uwzględnieniem NFSa.

The Network File System (NFS) - historia

Rozwój sieci dostarczających połączenia pomiędzy wieloma komputerami pozwolił na dostarczenie interfejsu takiego, aby programy użytkownika mogły mieć dostęp do rożnych plików poprzez sieć używając takich samych mechanizmów jakich używa do dostępu na lokalnym systemie plików.
Ponieważ w latach 70-tych i 80-tych dyski twarde były stosunkowo drogie umożliwiało to konstrukcje komputerów bez dysków twardych, lub z dyskami o bardzo małej pojemności.

NFS był początkowo rozwijany przez firmę SUN Microsystems w połowie lat osiemdziesiątych i stał się dużym sukcesem. Poniżej znajdują się cele jakimi kierowano się przy tworzeniu pierwszych dwóch wersji tego systemu:

dostarczyć komputerowi i systemowi operacyjnemu niezależność - miało to zapewnić, że NFS będzie mógł pracować zarówno na Unixowych jak i nie Unixowych systemach operacyjnych. Protokół klient/serwer musiał być wystarczająco prosty aby mógł zostać zaimplementowany na komputerach tamtego okresu, głównie z systmem DOS.
dostarczyć odporność na awarie serwera - w takiej sytuacji klient podłączony do serwera musi mieć możliwość dalszego działania. Co więcej nie powinien on zauważyć różnicy pomiędzy serwerem, który uległ awarii, a takim który po prostu wolno odpowiada.
dostarczy przeźroczysty dostęp do plików - aby system mógł zyskać popularność bardzo ważnym było, aby aplikacje miały dostęp do plików poprzez NFSa w taki sam sposób w jaki mają dostęp do plików na własnym dysku
zachować Unixowe własności plików na maszynie klienta - aby zaspokoić ten cel NFS udostępniał pliki zgodnie z ich atrybutami
dostarczać akceptowalną wydajność - ponieważ stwierdzono, że ludzie nie będą używać systemów plików wolniejszych od już istniejących granicę wydajności ustalono na 80% dostępu do lokalnego dysku.

Oryginalna implementacja NFSa obejmuje zarówno pierwsza jak i druga wersję protokołu, kiedy to po raz pierwszy udostępniono go publicznie w systemie SunOS 2.0 w 1985 roku. Pierwsza wersja tego protokołu była używana przez Suna tylko wewnętrznie.
W tym momencie trzecia wersja NFSa jest w powszechnym użyciu już przez kilka lat, ale pojawiła się wersja 4, która powoli zdobywa popularność. Zapowiada się, że NFS jest systemem który jeszcze przez przynajmniej kilka lat będzie najpopularniejszym rozproszonym systemem plików.

Wersja 1 i 2 protokołu NFS

Początkowo aby dostarczyć wsparcie dla NFSa firma Sun przeprojektowała swój system operacyjny SunOS, między innymi przystosowując go wielorakich typów systemów plików. Nie była to jedyna cecha jądra na której polegał NFS. Używał również infrastruktury zdalnego wywoływania procedur (Remote Procedure Call), która dostarczała synchroniczny, krzyżowy mechanizm sieciowy dla jednego procesu (lub jądra), aby umożliwić wywoływanie procesów na innej maszynie. Pozwoliło to podzielić protokół NFS w zbiór procedur uszczegółowiając ich argumenty, wyniki i efekty działania.
Do komunikacji poprzez sieć NFS używał protokołu "User Datagram Protocol" (UDP) nad protokołem internetowym (IP). Ponieważ był on zaprojektowany jako niezależny od architektury komputera i systemu operacyjnego kodowanie wiadomości i odpowiedzi było wrażliwe na kolejność pakowania bajtów w pojedyncze słowo maszynowe. Zmusiło to do użycia specyfikacji "External Data Representation" (XDR).
Użycie RPC i XDR zostało opisane w kolejnym podrozdziale. Przed dokładnym opisem ich działania dobrze jest poznać wywołania procedur wprowadzonych w NFS do komunikacji poprzez sieć. Plik do którego odwołują się wszystkie procedury jest nazywany "uchwytem pliku". Jest to struktura danych dostarczona przez serwer w odpowiedzi na żądanie wyszukania pliku. Klient nigdy nie powinien próbować jej interpretacji. Uchwyty są konstruowanie z informacji o operacjach na pliku, numeru i-węzła którego dotyczy i jego licznik pokoleń.
Serwer NFS jest bezstanowy, co oznacza, że na serwerze nie są trzymane żadne informacje dotyczące wcześniejszych wywołań. Zapobiega to skomplikowanym mechanizmom przywracania systemu po awarii. Jeżeli klient nie otrzyma odpowiedzi od serwera w określonym przedziale czasu żądanie jest ponawiane aż do osiągnięcia sukcesu. Podejście to powoduje, że awaria serwera lub jego restart są traktowane przez klienta jak dłuższe oczekiwanie na wolny serwer.
Wersja druga protokołu NFS wymaga również aby zapis plików odbywał się synchronicznie.
W uchwycie pliku zazwyczaj zakodowany jest licznik pokoleń. Rozważmy sytuację gdy plik zostaje otwarty i klient otrzymuje jego uchwyt. Jeżeli teraz plik zostanie usunięty z serwera i zwolniony i-węzeł zostanie użyty ponownie uchwyt przestanie być ważny gdyż odnosi się do starego pliku. Aby odróżnić stare pliki od nowych Unixowe systemy plików zawierają licznik pokoleń, które są powiększane za każdym razem kiedy i-węzeł jest używany ponownie. Dzięki temu stary uchwyt zostanie wykryty przez serwer kiedy następuje odwołanie do usuniętego pliku.

Eksportowanie, montowanie i dostęp do plików w NFS

Poniższa tabela przedstawia różne procedury protokołu NFS. Aby wywoływać procedury i wykonywać operacje na plikach potrzebny jest jednak dostęp do głównego katalogu. Uzyskuje się go poprzez oddzielny protokół montowania, który zwraca uchwyt głównego katalogu.
Dwa powody wpłynęły na rozdzielenie protokołu montowania od protokołu NFS. W pierwszym z nich sposób sprawdzania praw dostępu na serwerze jest zazwyczaj zaimplementowany w przestrzeni użytkownika i może używać różnych mechanizmów ochrony. Protokół NFS jest natomiast zaimplementowany w jądrze ze względów wydajnościowych i zdecydowano, że najłatwiej pozwolić na taki podział. Drugim powodem było to, że projektanci poprzez pojedynczą ścieżkę do procedury uchwytu za bardzo związaliby implementacje NFSa z Unixem.
Protokół montowania składał się z sześciu różnych procedur i pozostał niezmieniony przez długie lata. Od tamtego czasu została dodana tylko jedna procedura (umożliwiająca dostosowanie NFSa od standardu POSIX).

NFS na Unixie bazującym na systemie plików VFS

Użytkowanie NFSa

Chociaż implementacje NFSa różnią się pomiędzy platformami w zakresie eksportowania systemów plików jego użytkowanie jest bardzo proste gdy działają zarówno klient jak i serwer. Demony/wątki NFS zazwyczaj są inicjalizowane gdy system wchodzi w tryb wielu użytkowników.
Jako przykład weźmy Solarisa w którym serwer svr chce eksportować system plików zamontowany na /fs1 do dowolnego klienta. Najłatwiej to zrobić poprzez umieszczenie odpowiedniego wpisu w /etc/dfs/dfstab, który opisuje system plików który chcemy dzielić i/lub eksportować. Zapewnia to, że system plików będzie eksportowany przy każdym restarcie systemu. Jeżeli nie potrzebujemy żadnych opcji systemu plików wystarczy wpisać:

share -F nfs /fs1

Po stronie klienta trzeba go zamontować na przykład w taki sposób:

# mount -F nfs srv:/fs1 /mnt
# mount | grep mnt
/mnt on srv:/fs1 remote/read/write/setuid/dev=2fc004 on Wed Jun 19 07:25:18 2002

Tak zamontowany system plików może być teraz używany jak dowolny lokalny.

Wersja 3 protokołu NFS

Pomimo ogromnego sukcesu NFS 2 nie był pozbawiony wad. Dwa największe problemy, których starano się pozbyć projektując wersje 3 protokołu to:

Maksymalny rozmiar plików - 4 GB
Wymaganie wszystkich zapisów do wykonania zapisu synchronicznego powodowało wąskie gardło aplikacji intensywnie zapisujących dane.

Głównym celem w NFS 3 oprócz pozbycia się powyższych problemów było uporządkowanie istniejącego protokołu oraz dodanie kilku usprawnień, ale tak, aby nie stracić na wydajności.

Zapisy w Unixie są domyślnie asynchroniczne (co można jednak zmienić przekazując odpowiednie flagi do funkcji open). Wymuszanie jednak aby zapis asynchroniczny odbywał się synchronicznie znacznie zmniejsza wydajność. W NFS 3 klient może wysłać wiele asynchronicznych żądań zapisu, które później może zatwierdzić na dysku serwera przy pomocy komendy COMMIT. Kiedy serwer otrzyma takie żądanie serwer nie może normalnie pracować do momentu w którym wszystkie dane nie zostaną zapisane na dysku. Jest to duże usprawnienie gdyż pozwala to systemowi plików na serwerze lub sterownikowi dysku na zebranie wielu zapisów w jeden większy co jest bardziej efektywne. Użycie asynchronicznych zapisów nie powinno wpływać na dotychczasowe reakcje NFSa na awarie ponieważ klient jest zobowiązany do przetrzymywania kopii wszystkich danych przekazanych do zapisania aż do wysłania komendy COMMIT.
Procedura READDIRPLUS, która umożliwia zwracanie zarówno uchwytu pliku jak i jego atrybutów wyeliminowała dodatkowe żądania odczytu, ale spowodowała inne problemy. Ponieważ implementacja tej procedury jest znacząco droższa niż poprzedniej READDIR powinna być używana z rozwagą. Zazwyczaj operacja powinna być przeprowadzona tylko podczas pierwszego dostępu do pliku, a później tylko w wypadku gdy unieważniona została pamięć cache dotycząca katalogu poprzez jego modyfikację.
Ponieważ NFS 3 miał również na celu zwiększenie wydajności jego sukces zależał między innymi od tego jak dobrze działał ten mechanizm. Wiele różnych testów pokazało jednak, że trzecia wersja protokołu NFS sprostała także temu zadaniu.

Protokół NFS Lock Manager

Projektując NFSa postanowiono ominąć blokowanie plików. Chcąc to zaimplementować znacznie zwiększyłaby się złożoność implementacji NFSa.
Blokowanie plików nie jest jednak rzeczą o której łatwo zapomnieć więc wbudowano w system SunOS Network Lock Manager (NLM). pojawiło się wiele wersji tego protokołu, jednakże ze względu na złożoność samego rozwiązania nie było ono szeroko dostępne. Definicje odpowiedniego NLM były zawarte w specyfikacji NFSa 3, ale ciągle był osobnym protokołem. Poza tym współpracował on jeszcze z protokołem Network status Monitor, który był wymagany, aby do zawiadamiania klientów i serwera o awarii tak, aby można było później kontynuować pracę.

NFS 4 - co nowego?

NFS został zaprojektowany z myślą o lokalnych sieciach i rozwinął się przed erą WWW. W miarę upływu czasu pojawia się coraz większa potrzeba użycia NFSa w rozległych sieciach. Tutaj powstają pytania o bezpieczeństwo i możliwości NFSa w zakresie adresowania różnego rodzaju środowisk. Chociaż jednym z celów oryginalnego NFSa było wsparcie dla nie Unixowyxh platform protokół ciągle kierował się w stronę środowiska Unixowego.
Celami wersji 4 było więc pokonanie powyższych trudności oraz dostarczenie dodatkowych funkcjonalności niezaimplementowanych w wersji 3 (zmiany w wersji 3 zostały zminimalizowane, ale mieć pewności, że wszystko będzie gotowe na czas). Chociaż wersja 4 zawiera kilka znaczących zmian celem jest umożliwienie wprowadzania przyrostowych zmian, które nie będą wymagały przebudowy całego protokołu. Czas pomiędzy wersją 2 a 3 wynosił ok. 8 lat czyli mniej więcej tyle ile pomiędzy wersją 3 a 4. Mała poprawka w wersji 4 pozwala na dodawanie nowych funkcji w znacznie krótszych odcinkach czasu.
Najważniejsze zmiany wprowadzone w wersji 4 to:

Połączone procedury. Wiele operacji na plikach poprzez NFS wymaga dużej liczby wywołań procedur. W lokalnej sieci nie jest to duży problem. Operując jednak na rozległych sieciach efekt wydajnościowy jest dużo bardziej zauważalny. Poprzez łączenie wielu wywołań procedur w jedno ilość komunikacji może zostać zmniejszona co powoduje zwiększenie wydajności.
Wielonarodowość. We wcześniejszej wersji protokołu nazwy plików były reprezentowane jako strumień bitów. Chociaż były one ograniczone do 7 bitowej reprezentacji US ASCII powszechnie używały 8 bitowej ISO-Latin-1. Problemy pojawiły się ponieważ nie było sposobu na wyspecyfikowanie kodowania w reprezentacji danych XDR. Ograniczało to użycie NFSa w środowiskach z różnymi zestawami znaków. W NFS 4 pliki i katalogi używają nazw kodowanych przy pomocy UTF-8, więc powyższy problem nie występuje.
Ulotne uchwyty plików. NFS 2 i3 dostarczały jednego typy uchwytów z jednym zestawem semantyk. Taki uchwyt ma ustaloną wartość na czas istnienia systemu plików do którego się odwołuje. Na przykład uchwyt pliku w Unixie składa się m.in. z numeru i-węzła oraz licznika pokoleń. Ponieważ i-węzły mogą zostać zwolnione i przydzielone ponownie licznik pokoleń zwiększa się gdy i-węzeł jest użyty ponownie w celu upewnienia się, że uchwyt klienta, który odwoływał się do starego pliku nie mógł się odwołać do nowego pomimo iż numer i-węzła nie uległ zmianie.
Protokół NFS 4 rozdziela uchwyty na dwa rodzaje: trwałe (opisujące tradycyjne uchwyty) i ulotne. w tym drugim przypadku serwer nie zawsze może określić czy dany uchwyt jest ciągle ważny. Jeżeli wykryje że uchwyt został unieważniony zwraca odpowiedni komunikat o błędzie. Jeżeli jednak nie może zdecydować czy uchwyt jest ważny czy nie wysyła inny komunikat. Klient jest w stanie wykryć czy serwer może używać trwałych i ulotnych uchwytów i odpowiednio na takie błędy zareagować.
Klasy atrybutów. Zbiór atrybutów, który był przekazywany poprzez siec był we wcześniejszych wersjach NFSa ukierunkowany na Unixa. niektórych środowiskach te atrybuty były bez znaczenia, a z kolei w innych serwery nie były w stanie dostarczyć aktualnych danych.
W czwartej wersji NFSa zbiór atrybutów pliku został podzielony na trzy różne klasy atrybutów:
- podstawowych - informacje takie jak typ i wielkość pliku, informacje na temat wygaśnięcia uchwytu.
- zalecanych - informacje o właścicielu, grupie, czasach dostępu, atrybutach quoty. Zawierała również informacje systemu plików na temat wolnej przestrzeni na dysku, liczby plików, plików dostępnych do użytku, ograniczenia systemu plików [np. długość nazwy]
- nazwanych - umożliwia pojedynczemu plikowi na posiadanie wielu strumieni bitów w przeciwieństwie do tradycyjnego modelu Unixa.
Blokowanie plików. Jak wspomniałem wcześniej blokowanie nie jest częścią drugiej, ani trzeciej wersji protokołu NFS. Które jednak zamiast tego muszą używać protokołu NLM (Network Lock Manager)opisanego w jednym z powyższych podrozdziałów. Nie został on jednak najlepiej przyjęty.
NFS 4 umożliwia osobne systemy blokowania plików dla Unixa i Windowsa. Wspiera zarówno blokowanie rekordów jak i określonych zakresów bajtów.
Cache'owanie po stronie klienta. Większość klientów NFS zapamiętuje zarówno dane z pliku jak i atrybuty. Gdy przenosimy się do rozległych sieci koszt "nie trafienia" (cache miss) może być znaczący. Problem z wersjami 2 i 3 polegał na tym, że nie dostarczały one pośredników do łączenia pomiędzy wieloma klientami, co czasami może prowadzić do przeczytania nieważnych danych.
NFS 4 nie wprowadza łączników z klientami, ale definiuje minimalny zbiór danych dla których gwarantuje rezerwacje blokad (zwykłych i dzielonych) i na których klient może bez przeszkód operować. NFS 4 dostarcza także "schemat delegacji", który umożliwia klientowi podejmowanie decyzji tradycyjnie podejmowanych przez serwer.
Jest to ważne przy wydajności gdyż ogranicza liczbę wywołań procedur. Gdy inny klient poprosi o dostęp do pliku, którego delegacja została komuś przyznana serwer wysyła RPC do klienta który posiada te delegację. Jest on teraz odpowiedzialny za zapisanie wszystkich zmian na serwerze a następnie oddanie delegacji.
Wbudowana ochrona. NFS korzystał z mechanizmu Unixa weryfikacji użytkowników aby zapewnić ochronę. Nie było to zazwyczaj problemem, gdyż był on używany głównie w prywatnych sieciach. Biorąc jednak pod uwagę cele wersji 4 ten poziom zabezpieczenia nie był wystarczający. Podstawowe mechanizmy bezpieczeństwa NFSa zostały poszerzone poprzez implementacje dodatkowych mechanizmów w warstwie procedur RPC, które dostarczają zestawy prywatnych i publicznych kluczy.

Podsumowując, na pewno protokół NFS 4 jest znaczącą przeróbką wersji 3. Dostarcza szeroki zakres funkcji skierowanych w stronę rozległych sieci i na tym polu z pewnością odniesie sukces.

8. Klastrowe systemy plików

Po co to jest?

Problem z rozproszonymi systemami plików polega na tym, że w momencie w którym serwer przechowujący istotne dane zawiesi się, świadczone przezeń usługi są wstrzymywane do czasu aż się zrestartuje. Jeśli nie będzie możliwy natychmiastowy restart systemu to przerwa taka może być znacząca. Największe, kluczowe działy firm w dużej mierze zależą od zastosowanej w nich technologii komputerowych i jakiekolwiek opóźnienia mogą kosztować firmę sporo pieniędzy.

W celu stworzenia bardziej niezawodnego sprzętu, klastrowe systemy plików o ile nie usuwają całkowicie przestoi w dostawie usług, to przynajmniej je znacząco zmniejszają. W połączeniu z większą niezawodnością systemu oraz łącząc w jedną całość wiele serwerów, CFS stwarza możliwość lepszego wykorzystania zasobów i łatwiejszego zarządzania systemem, czyniąc z siebie istotną część każdego dużego przedsiębiorstwa.

Co to jest?

Krótko mówiąc jest to kolekcja serwerów(także zwanych węzłami), które współpracują ze sobą, aby zapewnić jednolity i całościowy obraz całego systemu plików. Jakikolwiek proces uruchomiony na którymś z tych komputerów widzi dokładnie to samo co każdy inny w pozostałych węzłach. Poza tym zmiana w jakimkolwiek węźle powoduję natychmiastową zmianę we wszystkich pozostałych.

Klastrowy system plików uzupełnia się z rozproszonymi systemami plików. Każdy węzeł może eksportować system plików, który może być później widziany przez sieć na przykład korzystając z NFS.

W rzeczywistości każdy węzeł może eksportować system plików, który później może być zamontowany u kilku innych klientów. Mimo, że klastrowe systemy plików mogą się różnić między sobą, to tym co je głównie odróżnia od rozproszonych systemów plików jest to, że muszą one w każdej chwili zapewniać jeden wspólny widok na cały system plików oraz pełną zgodność cache'y.

Jest kilka właściwości klastrowych systemów plików, które znacząco rozszerzają inne tradycyjne:

Odporność na awarię serwera
W przeciwieństwie do rozproszonych systemów plików, w których w momencie zawieszenia się serwera tracona jest świadczona przezeń usługa, w systemach klastrowych nie ma to znaczenia w sensie dostępu do klastra jako całości. Każdy inny serwer może przejąć obowiązki poprzedniego.
Odporność na awarię sprzętu
Klaster odporny jest również na wiele możliwych awarii sprzętu takie jak utrata dostępu do części sieci lub dysku. Ponieważ dostęp do klastra z reguły odbywa się przez wiele rożnych i niezależnych dróg, żądania mogą być przekierowane w zależności od tego co się popsuło.
Zawieszenie się aplikacji
Awaria jednego z serwerów może powodować zawieszenie działania jednej bądź większej liczby aplikacji, które były na niej uruchomione. Jednakże mając niektóre z nich cały czas uruchomione na innych serwerach w sieci w trybie czuwania, w momencie wykrycia awarii, pozwala to na natychmiastowe przejęcie przez inne odpowiedzialności tamtego serwera. W ten oto sposób jedyne co trzeba jeszcze zrobić to zrestartować działanie aplikacji. Restart całego system jest już zupełnie niepotrzebny.
Zwiększona skalowalność
Wydajność może być z reguły zwiększona po prostu przez dodanie dodatkowego węzła do klastra. W większości środowisk klastrowych, może to być zrobione nawet bez restartu całego klastra.
Lepsze zarządzanie
Zarządzanie zbiorem rozproszonych systemów plików wymaga zarządzania każdym z serwerów z osobna. Klastry i klastrowy system plików pozwalają sobą zarządzać jako jedna całość redukując nakłady.

W miarę jak klastry stają się coraz bardziej popularne, coraz bardziej jest rozwijana ich technologia narzucająca coraz mniejsze wymagania na warstwę sprzętową. W momencie w którym większa niezawodność i skalowalność jest zapewniana w większości przez oprogramowanie, serwery w klastrze będące z reguły drogimi zaawansowanymi serwerami, mogą być z powodzeniem zastąpione przez zwyczajne domowe PC-ty.

Komponenty Systemów Klastrowych

W celu osiągnięcia dostatecznie wysokiego poziomu jakości usług i zarządzania opisanych w poprzednich rozdziałach, niezbędne są pewne komponenty, które współdziałając ze sobą dostarczają wspomniane usługi. Następne rozdziały opisują różnorodne komponenty, które są wspólne dla wszystkich klastrów i klastrowych systemów plików.

Rozwiązania sprzętowe dla klastrów

Budując klaster jedną z pierwszych rzeczy do rozpatrzenia jest typ sprzętu którym dysponujemy. Typowe środowisko składa się ze zbioru klientów łączących się z serwerami za pomocą sieci Ethernet. Nośniki danych podłączone są do serwerów za pomocą SCSI bądź innego typu wejścia-wyjścia. Tak jak Ethernet i protokół TCP/IP do komunikacji pomiędzy komputerami raczej nie zostaną zastąpione w najbliższej przyszłości, tak model składowania danych rozwijał się przez ostatnie lata. Mimo, że nośniki danych dołączane przez SCSI pozostają ciągle popularne, podsystemy składowania zyskują coraz większą popularność. Nośniki danych mogą być fizycznie oddzielone od serwera za pomocą adaptora i przełącznika(switch) fibre channel, co pozwala na łatwe i efektywne tworzenie sieci składowania danych (storage area networks - SAN).

Zarządzanie klastrem

Skoro wszystkie węzły w kastrze są widziane jako całość, więc muszą być jakieś środki do grupowanie i usuwania węzłów z klastra. Jest też niezbędne, aby jakiekolwiek awarie w obrębie klastra były wykrywane jak najszybciej i umożliwiało to szybki restart systemu. Wymagane jest to od wszystkich składników wchodzących w obręb klastra takich jak: system plików, zarządca woluminów i zarządca blokad. Wykrycie awarii jest najczęściej osiągane przez pewien rodzaj mechanizmu "bicia serca". Na przykład jeden z węzłów może być odpowiedzialny za ping-owanie innych węzłów, które muszą odpowiedzieć na żądanie w jakiś przedziale czasu. Jeśli węzeł nie odpowiedział bądź ileś bić nie zostało zatwierdzonych, możliwe jest że dany węzeł uległ awarii. Wtedy następuje wywołanie mechanizmu przywracania prawidłowego działania systemu. Oczywiście ten mechanizm jest wrażliwy na awarię węzła nasłuchującego. To jednak może być rozwiązane przez wprowadzenie wielu takich serwerów wraz z możliwością awansu jednego z pozostałych węzłów w przypadku awarii.

Klastrowy Zarządca Woluminów

We większych środowiskach serwerowych dyski są z reguły zarządzane przez użycie Zarządcy Woluminów. Zamiast udostępniać kawałki dysku na których można zakładać systemy plików, udostępnia on zbiór woluminów logicznych. Woluminy takie wyglądają dla użytkownika tak samo jak kawałek dysku na który składa się ciągły zbiór bloków dyskowych, ale tak naprawdę może on składać się z wielu rozproszonych wycinków różnych dysków.

Może to być wolumin RAID-1, który zapewnia bezpieczeństwo przed uszkodzeniem się jednego z dysków tworząc kopie tego samego woluminu na dwóch lub więcej różnych dyskach.

Dodatkowo do tych podstawowych typów woluminów, dane mogą one być również rozdzielone pomiędzy więcej dysków(RAID-0). Dane alokowane są w blokach o stałej długości. Na rysunku widać logiczny wolumin w którym dane są rozdzielone pomiędzy trzy dyski i rozmiar bloku wynosi 64KB.

Pierwsza cześć 64KB jest zapisana na pierwszym dysku, następna na drugim, trzecia na trzecim i tak dalej. Ponieważ dane są podzielone pomiędzy wiele dysków można przez to zwiększyć zarówno pisanie jak i czytanie, ponieważ dane mogą być zapisywane do wszystkich dysków jednocześnie.

Zarządca woluminami może również zapewniać software'ową implementacje RAID-5 gdzie jednocześnie dane są chronione przed uszkodzeniem jednego z dysków jak i zwiększona jest prędkość operacji.

W środowisku opartych na SAN gdzie wszystkie serwery mają dostęp do podrzędnych nośników danych, zarządzanie składowiskiem i alokacja logicznych woluminów musi być koordynowana między rożnymi serwerami. To wymaga istnienia na każdym z nich Klastrowego Zarządcy Woluminów, który porozumiewa się ze innymi, aby zapewnić jednolity widok na całe składowisko danych. Zapobiegania to nadpisaniu przez jeden serwer danych konfiguracyjnych drugiego. Stworzenie logicznego woluminu w jednym węźle klastra jest widoczne dla wszystkich pozostałych węzłów. To pozwala na równoległe działanie aplikacji na różnych serwerach. Jako przykład można podać Oracle RAC(Reliable Access Cluster), który może być uruchomiony w każdym węźle klastra i mieć dostęp do tej samej bazy danych przez Klastrowego Zarządce Woluminów. Jest on niewrażliwy na uszkodzenie jakiegokolwiek węzła, bo wszystkie pliki konfiguracyjne są współdzielone przez wszystkie węzły.

Zarządca Klastrowego Systemu Plików

Zadaniem klastrowego systemu plików jest zapewnienie takiego samego widoku na system plików w każdym węźle klastra. Jak wiadomo zapewnienie spójności pomiędzy cache'ami różnych węzłów nie jest prostym zadaniem. Dodatkową trudnością jest współdzielenie zasobów pomiędzy wszystkimi węzłami sieci. Założenie blokady do zapisu/pisania do zasobu w jednym węźle jest niewystarczające, bo jakiś proces w innym węźle mógł zrobić to samo. Przypadek gdy węzeł jest dodawany do klastra lub jest z niego usuwany w przypadku awarii też musi być wzięty pod uwagę. Co ma się dziać jeśli jeden z elementów klastra zawiedzie? Mechanizm wznawiania poprawnego działania systemu musi istotnie różnić się od tego widzianego w rozproszonych systemach plików.

Lokalny system plików musi być zmodyfikowany, aby wziąć to wszystko pod uwagę. Każda operacja musi być tak zmieniona, by dostosować się do działania klastra. Niezbędny jest model transakcyjny systemu plików. Jeśli jeden węzeł zawiedzie, inny musi przejąć jego zadania i wznowienie działanie systemu musi odbyć tak szybko jak to możliwe. Są dwa modele dla budowania klastrowych systemów plików:

Serwery pojedynczych transakcji
W tym modelu tylko jeden z węzłów, węzeł główny, dokonuje transakcji. Mimo, że każdy węzeł w klastrze może dokonywać operacji wejścia-wyjścia, to jeśli musi być dokonana jakaś strukturalna operacja w systemie plików, każdy inny węzeł musi przesłać żądanie do węzła głównego, aby ten dokonał tej operacji.
Serwery wielokrotnych transakcji
W tym modelu każdy węzeł może dokonywać transakcji.

Oba z tych typów ma swoje zalety i wady. Typ z pojedynczymi transakcjami jest prostszy do implementacji, ale główny węzeł może stać się wąskim gardłem w systemie w którym dokonywane jest wiele operacji na meta-danych. Poza tym są dwa podejścia do tworzenia takich systemów.

Pierwszy polega na nadbudowaniu komponentów klastrowych na lokalny system plików. Jest to prostsze do implementacji. Nie potrzebna jest znajomość implementacji podstawowego systemu plików, ale trudności powstają kiedy cechy poszczególnych systemów wpływają negatywnie na działanie całego klastra.
Drugie podejście polega na przekształceniu lokalnego systemu plików, tak aby był "świadomy" pracy w klastrze. Wszystkie operacje i blokady muszą być dostosowane do działania w klastrze i po ewentualnym załamaniu się systemu musi on potrafić odzyskać wszystkie informacje o klastrze.

Klastrowy Zarządca Blokad

Systemy plików, zarządca woluminów i inne oprogramowanie systemowe wymaga innego typu blokad by koordynować dostęp do ich struktur danych. Rozważmy sytuacje w której dwa różne procesy próbują zapisać do tego samego pliku. Zwyczajna blokada oparta na lokalnym systemie plików musi być rozszerzona by zapewnić działanie jako blokady rozproszonej dla wszystkich węzłów sieci. Takie blokady mogą być żądane i brane przez każdy inny węzeł klastra. Działanie blokad jest zapewniany przez Globalnego Zarządcę Blokad (global lock manager - GLM). Zadanie GLM musi znacząco wykraczać poza zwyczajne przyjmowanie żądań, dawanie i zwalnianie blokad. Musi on też być w stanie odzyskać blokady wzięte przez węzeł, który właśnie uległ awarii.

Co korzysta z CFS?

współdzielenie dużych ilości danych - takich jak np. obraz wideo, wiele aplikacji musi je po kolei obrobić, w momencie w którym mamy jeden wspólny system plików, ułatwia to administrację danymi
Web farms - mamy wiele serwerów udostępniających te same dane oraz program, który równoważy obciążenie poszczególnych serwerów; utrzymywanie tych samych danych na różnych serwerach może prowadzić do ich niezgodności, zastosowanie CFS umożliwia automatyczne działanie takich środowisk oraz gwarantuje większą niezawodność w przypadku gdyby któryś z tych serwerów uległ awarii
Oracle RAC (Real Application Cluster) - łatwo jest rozszerzyć bazę danych i obsługa dla wielu czytelników i pisarzy

9. Porównanie szybkości działania systemów plików

Porównanie objęło sześć rożnych systemów plików:

Ext2
Ext3
Jfs - czyli Journaled File Sysytem powstał w 1990 roku w firmie IBM dla systemu AIX, pierwsza wersja dla Linuxa w luty 2000 roku
Xfs - opracowany przez Silicon Graphics Inc. (SGI), system pierwotnie przeznaczony dla systemu operacyjnego IRIX
Reiserfs
Vfat - system plików MSDOS'a

Testy dla małych plików

Kopiowanie

Tutaj mierzymy czas w sekundach przekopiowania około dziesięciu tysięcy małych plików pomiędzy różnymi systemami. Pierwszy człon oznacza pierwotny system plików z którego kopiujemy, a drugi docelowy, gdzie mamy skopiować.

Wydaje się, że połączenie ext2/ext3 jest dobra kombinacją jeśli wykonuje się dużo operacji kopiowania dla małych plików. Ale mimo to xfs i reiserfs są wystarczająco dobre, bo obserwujemy tylko 10%-20% spadek wydajności przy pisaniu do tych systemów plików.

Oczywiście stary vfat jest najgorszy w tym przypadku, ale zaskakująco jfs okazuje się nie wiele lepszy.

Kasowanie

Teraz będziemy mierzyć czas skasowania dużej ilości małych plików z danego systemu.

Tak w tym przypadku mamy zdecydowanego zwycięzcę. Jest nim ReiserFS, który okazał się dwa razy szybszy od wszystkich pozostałych systemów. Jeśli nie liczyć vfat jako liczącego się systemu plików pod Unix'a to nawet trzy razy szybszy. Xfs okazuje się być zaskakująco słaby w kasowaniu dużej ilości plików i katalogów.

Czytanie

Tutaj będziemy czytać wiele małych plików z dysku.

Tutaj nie można zauważyć istotnej różnicy pomiędzy różnymi systemami. Obserwujemy zaledwie 20% różnicę pomiędzy najlepszym i najgorszym.

Pisanie

A teraz spróbujemy zapisać tysiące małych plików.

Wygląda na to, że ext2 jest świetnym systemem, żeby do niego zapisywać. Ext3, xfs i reiserfs wypadają też całkiem dobrze.

Podsumowanie

Trudno jest powiedzieć, który system jest idealny dla obsługi małych plików. Ext2 i ext3 okazują się być bardzo dobre w przypadku pisania do pliku, ale prędkość kasowania dla systemu reiserfs może mieć decydujące znaczenie przy wyborze, którym systemem się posłużyć.

Testy dla dużych plików

Kopiowanie

Tutaj mierzymy czas w sekundach przekopiowania jednego dużego pliku rozmiaru 650 MB z jednej partycji na drugą. Pierwszy człon oznacza system plików macierzystej partycji z której kopiujemy, a drugi docelowy, gdzie mamy skopiować.

System plików Xfs jest najlepszy we prawie wszystkich testach w których jest on partycją docelową, chociaż Ext3 jest tylko parę sekund w tyle. To można najlepiej zobaczyć poniżej przy porównaniu czasu zapisu. Wszystkie pozostałe systemy są ponad 50%-100% w tyle. Vfat jest oczywiście znowu najgorszy do którego można zapisywać. Jeśli porównywać odczyt różnice mimo wszystko nie są aż tak znaczące jakby mogłoby się wydać, co widać przy teście odczytu z pliku.

Kasowanie

Tutaj skasujemy jeden duży plik z dysku.

Jeśli chodzi o kasowanie dużego pliku to każdy z systemów wykonuje je wystarczająco szybko.

Czytanie

Teraz przeczytamy z pliku o rozmiarze 650 MB dane.

Jak widać nie ma tak naprawdę znaczącej różnicy w czytaniu z dużych plików dla prawdziwych Unix'owych systemów plików, a vfat takim na pewno nie jest.

Pisanie

A teraz do niego zapiszemy.

Jeśli chodzi o pisanie to xfs jest najlepszy, ale ext3 jest prawie równie dobry. Wszystkie pozostałe okazują się być o wiele wolniejsze, a vfat tradycyjnie jest zastraszająco wolny.

Podsumowanie

No cóż wydaje się oczywiste, że jeśli przesuwa się często wiele dużych plików system Xfs może pozwolić zaoszczędzić trochę czasu. Ext3 jest również wystarczająco dobry. A jeśli naprawdę chcesz iść do kuchni zrobić sobie kanapkę, zjeść ją, wrócić i zobaczyć że kopiowanie jeszcze się nie skończyło, najlepiej zachować stare partycje windowsowe, bo system vfat jest wprost wymarzony dla Ciebie.

Podsumowanie końcowe

Jedno jest pewne, trudno jest wskazać jednego zwycięzcę.

ext2
- testy wykazały, że ext2 jest dobrym wyborem przy kopiowaniu małych plików , co jest bardzo istotne dla przeciętnego użytkownika. Jeśli chodzi o duże pliki nie jest on tak dobry jak inne, ale jest nadal przyzwoicie dobry.
- oczywiście ext2 nie jest kronikowanym systemem plików i co za tym idzie ma mniejsze zalety niż xfs, ext3, reiserfs i jfs.
ext3
- okazał się być drugi zarówno w zapisywaniu dużych jak i małych plików
- jest systemem z kroniką, więc wydaje się być dobrym wyborem
jfs
- w tych testach rozczarowuje
reiserfs
- okazał się przeciętny w zapisie zarówno małych jak i dużych plików
- jeśli chodzi o kasowanie to jest mistrzem w usuwaniu wielu plików z dysku
vfat
- ostatni prawie we wszystkich testach, najwyższa pora pozbyć się wszystkich starych partycji windows
xfs
- z testów wynika, że jest on dobrym wyborem, ale rozczarował trochę w szybkości usuwania wielu małych plików

Jaki system wybrać?

Nie można tego jednoznacznie powiedzieć, prawdopodobnie wydajność poszczególnych systemów plików znacząco się zmieniła od czasu przeprowadzenia tego testu, szczególnie systemu jfs. Mimo to można z pewnością powiedzieć, że nie warto stosować już starego systemu ext2, skoro ext3 jest równie wydajnym i bezpieczniejszym systemem z kroniką. Poza tym korzystanie z niego wymaga jedynie posiadania jądra Linuxa ze wkompilowaną obsługą Ext3 i zamontowania partycji Ext2 tak jakby była partycją Ext3, bo jest z nim w pełni kompatybilna.

10. Bibliografia

"UNIX Filesystems: Evolution, Design, and Implementation" - B.Goodheart, J. Cox
System plików ext3: http://www.zip.com.au/~akpm/linux/ext3/
"Understanding th LINUX kernel" - Daniel P.Bovet, Marco Cessati
U. Vahalia, Jądro systemu UNIX. Nowe horyzonty, WNT, 2001.

powrót

Copyright by Michał Kaczmarczyk, Piotr Malinowski & Dominik Wojtczak 2004 14 styczeń 2004

Device	Boot	Start	End	Blocks	Id	System
/dev/hda1	*	1	3	22648+	83	Linux
/dev/hda2		556	630	567000	6	FAT16
/dev/hda3		4	12	68040	82	Linux swap
/dev/hda4		649	2584	14636160	f	Win95 Ext'd (LBA)
/dev/hda5		1204	2584	10440328+	b	Win95 FAT32
/dev/hda6		649	1203	4195737	83	Linux