Pytanie w związk [!!!_DŁUGIE_!!!]

Czw, 10 Lip 2003, 15:06:47 CEST

Dnia Thu, 10 Jul 2003 10:23:21 +0200
Osoba skrywająca się za mailem < Jacek Konieczny <jajcus w bnet.pl> > napisała:

> Ja bym prosił jeszcze o wynik polecenia "stat" na różnych plikach.
> Nie wyobrażam sobie uniksowego systemu plików bez inodów, może w riserze
> nie są pod nie rejestrowane specjalne struktury i nie ma z tym
> związanych limitów, ale i-węzły w jakiejś postaci być muszą. Chociażby
> po to, by zapisać prawa do plików.

heh nie wytrzymałem oto "skrócona" budowa ReiserFS:

System ten po pierwsze wyrównuje granice plików z blokami na dysku dzięki
czemu minimalizuje liczbę bloków zajmowanych przez plik (przydatne w przypadku
plików składających się z wielu bloków), unika marnowania przestrzeni dyskowej
i buforowej nie przechowując niedopełnionych bloków. Zachowuje pliki i nazwy
plików w drzewach zrównoważonych przez co wydajniej upakowywuje dane na
dyskach i przez co _nie przydziela stałej przestrzeni na i-węzły_. 
Sama architektura systemu ma parę słabości, przykładowo brak buforowania
wejścia-wyjścia, co zostało ominięte przez unikanie dostępu do plików w małych
blokach. Zabawy w dopisywanie pojedynczych bajtów i wymuszanie synchronizacji
danych wyraźnie pokazuje słabość Reisera w takiej sytuacji... Podobnie
ReiserFS ma problemy z dużymi plikami - nie ma żadnych optymalizacji z nimi
związanych i jest gorszy od ext2fs pod względem przyśpieszania operacji
wejścia-wyjścia na tych plikach. Jeśli chodzi o spójność danych to ReiserFS
stosuje metodę odtwarzalności polegającej na unikaniu nadpisywania starych
metadanych, zapisując w ich pobliżu nowe.
Struktury drzewiaste używane przez Reiser'a są wyposażone w zbiór kluczy
definiowanych przez aplikacje, a ich podstawowym celem jest optymalizowanie
wyszukiwania za pomocą tych kluczy. Klucze te są używane w systemie plików
_zamiast numerów i-węzłów_, a więc odwzorowywane są klucze na położenia węzłów
wewnętrznych zamiast odwzorowywania numerów i-węzłów na położenia plików jak
to jest w innych systemach plików. Klucze te są dłuższe niż numery i-węzłów,
ale nie ma potrzeby buforowania tylu kluczy ilu i-węzłów, gdy w jednym węźle
przechowuje się więcej niż jeden plik. Wadą drzew jest to że wymagają
analizowania nazwy pliku składnik po składniku. Każde drzewo składa się z
trzech rodzajów węzłów: wewnętrznych, sforamtowanych i niesformatowanych.
Zawartość dwóch pierwszych jest posortowana według kolejności kluczy (te
trzecie nie zawierają kluczy). W tych drzewach pierwszy (dolny) poziom składa
się z węzłów niesformatowanych, przedostatni ze sformatowanych a wszystkie
wyższe z węzłów wewnętrznych. Wszystkie ścieżki od korzenia do każdego
sformatowanego węzła mają tą samą długość tak samo jak ścieżki do liści
niesformatowanych (te są od poprzednich o jeden węzeł dłuższe) - ma to
niebagatelny wpływ na wydajnośc. Węzły sformatowane składają się z czterech
typów elementów: bezpośrednich, pośrednich, katalogowych i statystycznych.
Każdy z tych elementów zawiera niepowtarzalny klucz dzięki któremu są
sortowane i można je wyszukiwać. Elementy bezpośrednie zawierają końcówki
plików (file_size mod block_size), pośrednie zaś wskażniki do
niesformatowanych węzłów które przechowywują całą zawartość pliku bez
końcówki, elementy katalogowe zaś zawierają klucz wpisu katalogowego. Dzięki
temu pliki w RaiserFS składają się ze zbioru elementów pośrednich i najwyżej
dwóch elementów bezpośrednich (tylko w sytuacji gdy końcówka pliku rozdzielona
jest na dwa węzły). Jeśli końcówka pliku jest większa niż maksymalny rozmiar
pliku mogącego pomieścić się w węźle niesformatowanym, ale jest mniejsza niż
rozmiar węzła niesformatowanego (4kb) to zostaje zapisana w weźle
niesformatowanym a wskaźnik do niej jest przechowywany w elemencie pośrednim.
Katalogi w ReiserFS składają się natomiast ze zbioru elementów katalogowych,
które zbudowane są ze zbioru elementów wpisów katalogowych zawierających nazwę
i klucz pliku (to tak jak katalog główny w bibliotece->katalog rzeczowy->autor
i tytuł, tak mniej więcej ;)). Każdy pierwszy element pliku lub katalogu
zawiera jego dane statystyczne. 
Klucze posiadają następjącą strukturę: identyfikator lokalności (locality_id),
identyfikator obiektu (object_id), przesunięcie (offset) i niepowtarzalność
(uniqueness). ReiserFS przechowuje w elemencie jeden klucz na podstawie
którego jest w stanie wyliczyć pozostałe. W przypadku katalogów przesunięcie
klucza określa cztery pierwsze bajty z nazwy pliku, a dzięki polu
niepowtarzalności można odróżniać nazwy plików mające taki sam początek. Każdy
plik ma swój niepowtarzalny identyfikator obiektu, jednakże nie można go użyć
do wyszukiwania obiektów, do tego ReiserFS używa kluczy.
Budowa struktur ReiserFS'a. Drzewo ma określoną maksymalną wysokość wynosząca
domyślnie 5. Drzewo to jest przechowywane w blokach dysku, każdy blok należący
do drzewa ma nagłówek bloku. Wszystkie obiekty systemu plików przechowywane są
jako zbiór elementów. Każdy element ma swój nagłówek (tem_head) zawierający
klucz elementu i parę innych dodatkowych informacji. Maksymalna ilość obiektów
w przestrzeni nazw ReiserFS wynosi 2^32-4 (czyli 4 294 967 292). Struktura key
ma rozmiar 16 bajtów, struktura disk_child (która jest rzeczywistym
wskaxnikiem do bloku dysku) ma rozmiar 6 bajtów, struktura block_head ma
rozmiar 22 bajty. Podstawowe informacje o pliku takie jak właściciel, grupa,
rozmiar, czas dostępu/modyfikacji/zmiany i-węzła, prawa dostępu zawarte są w
nagłówku elementu. Maksymalna długość nazwy pliku to rozmiar bloku - 64 czyli
dla bloków 4KB 4032 bajty. 
Jedną z ważnych cech systemu plików ReiserFS jest rejestrowanie z
wyprzedzeniem. Zdecydowana większość operacji na metadanych dotyczy więcej niż
jednego bloku co powoduje, że w sytuacji kiedy zostaną zaktualizowane tylko
niektóre bloki metadane zwykle ulegają uszkodzeni. Rejestrowanie z
wyprzedzeniem powoduje że bloki najpierw wędrują do dziennika, potem dopiero
na właściwe miejsce. Dzięki temu w razie krachu systemu RaiserFS wykonuje
zmiany zapisane w dzienniku co powoduje przywrócenie stanu systemu plików do
wyglądu sprzed kracha. To uspójnianie danych przebiega znacznie szybciej niż
fsck z tego względu że nie mieli całego dysku tylko obszar dziennika który
jest z definicji mniejszy od rozmiaru dysku (i to wyjaśnia nam czemu tak
szybko "wstaje" reiser).  ReiserFS wspiera mechanizmy dziennikowe takie jak:
- transakcje 
- transakcje wsadowe
- asynchroniczne zatwierdzenia
- wybiórcze opróżnianie buforów
- rejestrowanie bloków danych

To wszystko (w skrócie :>), mam nadzieję że to Wam troszke przybliży zasady
działania ReiserFS'a, jeśli macie jakieś pytania jeszcze to pytajcie -
odpowiem o ile sam będę wiedział :) (BTW: sorx za wszystkie literówki i orty
jeśli się zdarzyły)

Pozdrawiam.
-- 
 .-[x][_][#]---------------------= Signature =-------------------------[*]-.
 |  Mariusz 'Ma-rYu-sH' Witkowski | Founder CHInc. | Memeber PSI & SzLUUG  |
 `-------------------------. feci, quod potui, faciant meliora potentes .--'
                           `----= http://www.arachnoid.com/boycott/ =---'