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

Czw, 10 Lip 2003, 15:23:14 CEST

Wow.
Mam tylko jedna uwage: szkoda, ze nie tworzysz dokumentacji do PLD...
I jedno pytanie - dalej.

> 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ą

Czy to oznacza, ze odwzorowanie klucze -> numery i-węzłów moze byc
niejednoznaczne (dwa pliki moga dostac ten sam nr i-węzła) lub tworzone
dynamicznie (nie ma gwarancji, ze po przemontowaniu fs-u plik dostanie ten
sam nr i-węzła) ?

> 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/ =---'
> 
> __________________________________________________________
> nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
> 
> 

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology