Pojęcia związane z systemami plików

Wstęp

Czy defragmentacja na Linuksie to rzeczywiście mit? Czym jest księgowanie? Jak wygląda sprawdzanie systemu plików po odcięciu zasilania? Tutaj znajdziesz bardzo ogólne wprowadzenie w pojęcia związane z systemami plików.

Linuksa nie trzeba defragmentować

Popularny skrót myślowy propagatorów Linuksa jest z grubsza prawdziwy. Wszystko jednak zależy od tego, do czego komputer z Linuksem ma służyć i jaki system plików na nim zastosujesz.

Wyobraźmy sobie sytuację, w której wgrywamy na dysk bardzo dużo małych plików. Zajmują one całą przestrzeń partycji. Następnie kasujemy 1GiB losowo wybranych pliczków i wrzucamy tam cały plik o wielkości 1GiB. Jak myślisz, na ile kawałków go poszatkuje? Ups.

Nadajmy teraz tym teoretycznym plikom jakieś zastosowanie. Załóżmy, że wszystkie małe pliki to pliki tekstowe, których używa skrypt jakiegoś dużego forum (wiem, normalnie do tego służą bazy danych) a jednogigabajtowy plik pochodzi z loga Apache, który ma coś nie tak w konfiguracji i co chwila zapisuje do niego. Dla ułatwienia załóżmy też, że każdy pliczek reprezentuje jeden wątek na forum. Przydałoby się jeszcze +10% wolnego miejsca na tej partycji. A teraz symulacja: co by się stało na Windows? Najpewniej wszystko poszatkowałoby się na tysiące jeszcze mniejszych kawałeczków. Co się stanie na Linuksie? Wraz z kolejnymi zapisami system plików będzie przenosił te pliki w całości do jakiegoś większego wolnego obszaru, zaś przy okazji zapisywania loga również będzie go powoli kompletował w całość. Po pewnym czasie używania wszystko będzie w całości.

Należy przy tym dodać, że sposób używania loga (tylko dopisywanie) nie wymaga jego obecności w jednym kawałku.

Warto zauważyć, że założeniem powyższego przykładu był regularny zapis. Nie wszystkie sposoby użytkowania stwarzają jednak takie warunki. Łatwo można sobie wyobrazić okoliczności, w których najlepszy system plików sobie nie poradzi i pofragmentuje dane jak polski asfalt na mrozie. Dlatego powstały linuksowe defragmentatory. Tak, takie coś istnieje! Zwykłemu użytkownikowi nie są przeważnie do niczego potrzebne, ale warto wiedzieć, że istnieją. Najśmieszniejszy z nich to defrag Cona Kolivasa, który działa z (prawie) każdym systemem plików obsługiwanym w Linuksie, nawet takim którego nie znano w trakcie pisania defraga. Jedyne co robi to usuwa plik i zapisuje go na nowo (poczynając od największego). Należy go po prostu skopiować do katalogu, który chce się zdefragmentować i uruchomić z roota (a więc wrzucenie do / powinno zdefragmentować wszystko). Więcej informacji o defrag, w tym wyniki jego działania i zmodyfikowany skrypt na jakilinux.org.

Linuksowe systemy plików posiadają też defragmentatory z prawdziwego zdarzenia, czyli takie które same optymalizują strukturę. Posiadają?... EXT4 będzie zawierał własny defragmentator, zaś XFS zawiera namiastkę tego czegoś o nazwie fsr_xfs (lub xfs_fsr). Wszystkie przedstawione tu defragmentatory działają na podmontowanym systemie plików (online defragmentation), co nie znaczy że nie istnieją inne (komercyjny O&O, ostatnie wydanie w 2003 roku – lepiej tego nie próbować ;) ).

Aby poznać wartość fragmentacji Twojego systemu plików poszukaj na tej stronie (ctrl+F) słówka contiguous (w konsoli).

Księgowanie

Co się dzieje, gdy nagle zabraknie prądu? Wszelkie operacje zapisu na dysku zostają przerwane, nawet jeśli nie zostały dokończone.

Efekty tego mogą być następujące:

A więc co robi system, żeby nie pozwolić na problemy? Po restarcie uruchamiany jest specjalny program, który porównuje informację o istniejących plikach ze stanem faktycznym. Zajmuje to trochę czasu i nie zawsze daje pozytywne efekty.

Dlatego wymyślono księgowanie. Bardzo upraszczając, przed zapisaniem czegoś na dysk system plików zapisuje najpierw do dziennika informację o tym, co, gdzie i w jakiej ilości zostanie zapisane (metadane). Następnie opisane w metadanych dane są faktycznie zapisywane i jeśli wszystko przebiegnie pomyślnie, informacja o planowanym zapisie zostaje usunięta z dziennika. Dzięki temu po awarii prądu natychmiast widać jak na dłoni, które operacje nie zostały dokończone i sprawność systemu plików może zostać natychmiast przywrócona. Niestety kończy się to przeważnie utratą zapisywanych danych (które zostaną usunięte nawet jeśli zostały już zapisane – nie ma informacji o tym w dzienniku – jednak system plików pozostaje sprawny). Tak w dużym uproszczeniu wygląda księgowanie typu ordered w ext3 i ext4. Ciekawą, choć wolniejszą alternatywą jest księgowanie typu journal (znów ext3 i ext4), które dane przeznaczone do zapisu zapisuje najpierw w dzienniku, a później na dysk we właściwe miejsce. Dzięki takiemu księgowaniu nie tylko unikamy błędów w systemie plików, ale również nie utracimy danych, które dysk twardy zdążył zapisać przed awarią zasilania. Księgowanie writeback to takie, w którym pierwszeństwo zapisu informacji do dziennika i faktycznych danych nie jest określone. Przy tym trybie księgowania po odcięciu zasilania pliki zapisywane na krótko przed nim mogą zawierać niepoprawne dane, jednak – ponownie – integralność samej struktury systemu plików nie ulega naruszeniu. O księgowaniu w ext3 szerzej można poczytać tu.

Spójrzmy jeszcze raz na wymienione poprzednio defekty:

Osobną kwestią jest czy dane oraz metadane rzeczywiście zostaną zapisane w tej kolejności w jak sobie życzą twórcy systemu plików. Powodem tego jest pamięć podręczna dysku, używana do buforowania danych. Dzięki buforowaniu dysk może zgromadzić większą ilość danych do zapisania w jednym miejscu, przez co ograniczane są ruchy głowicy i zapis odbywa się szybciej. Problem w tym, że dysk z pamięci podręcznej na talerze zapisuje co chce i kiedy chce. Dlatego systemy plików z księgowaniem wymuszają zapisanie całego cache na dysk (ext 3 i ext4 domyślnie co 5 sekund – commit interval). W połączeniu z tak zwanymi barierami (XFS i EXT4) można mieć pewność, że struktura systemu plików nie zostanie uszkodzona przez zapisanie metadanych o rzekomo przeprowadzonych operacjach przy nieadekwatnym zapisie danych. Dlatego niepoprawne metadane zwykle pojawią się na źle skonfigurowanych kontrolerach RAID (czyli wiele dysków współpracujących ze sobą), gdzie występuje podwójna pamięć podręczna – kontrolera i dysków. Ciekawą funkcją jest sprawdzanie sumy kontrolnej dziennika, która umożliwia zapis danych i metadanych w niekoniecznie takiej kolejności, co przyspiesza operacje dyskowe (wszak jedna transakcja danych i metadanych musi wygenerować konkretny dziennik o określonej sumie kontrolnej; jeśli suma się nie zgadza, dziennik jest nowszy niż dane). W ext4 journal checksumming jest na razie wyłączone z powodu możliwych problemów bezpieczeństwa danych, także opisany tu mój "pomysł jak to ma działać" może nie być do końca dobry.

Jak działa sprawdzanie przy starcie?

Partycja root (/)

Po tej całej teorii czas zacząć od początku, czyli od uruchomienia systemu. Skrypty startowe Linuksa używają do sprawdzania jakiegokolwiek systemu plików polecenia fsck, fsck zgaduje z jakim systemem plików ma do czynienia, po czym uruchamia narzędzie odpowiednie dla wykrytego systemu plików (e2fsck dla EXT, reiserfsck dla reiserfs, można także korzystać z programów fsck.[nazwa systemu plików], na przykład fsck.ext3. Są to linki symboliczne lub skrypty odwołujące się do odpowienich programów. Pytanie: dlaczego po awarii prądu przywrócenie pełnej sprawności systemu zajmuje zwykle kilka niezauważalnych sekund, a przy zaplanowanym sprawdzeniu dysk "mieli" nawet pół godziny?

Wróćmy do procedury uruchamiania. Najpierw partycja / montowana jest w trybie tylko do odczytu. Kolejno uruchamiane jest polecenie /sbin/fsck -C -a. Opcja -C odpowiada za ładny wskaźnik postępu, zaś opcja -a jest... przestarzała. Końcowy efekt jest taki, że e2fsck interpretuje ją jako -p, a reiserfsck podobnie (ta i inne nieobjaśnione flagi zaraz zostaną pokazane na przykładzie). Inaczej zachowuje się fsck na systemie plików xfs, gdzie nie podejmuje żadnego działania, co zostało wyjaśnione niżej.

Skrypt startowy zawiera jeszcze zmienną, która w razie potrzeby dodaje opcję -f, która wymusza sprawdzenie na ext. Domyślnie bowiem ext3 nie podejmie procesu skanowania, jeśli jego zdaniem system plików jest w porządku (clean). Można się łatwo domyślić, że ta opcja zostanie dodana przy zaplanowanym sprawdzaniu, nie zostanie zaś dodana po niespodziewanym resecie, gdyż flaga podmontowanych wtedy systemów plików ustawiona będzie na unclean.

Różnica między flagą -p, a zwykłym sprawdzeniem jest ogromna. Zwykłe sprawdzenie zdefiniujemy jako -f -y dla ext i -y dla reisera. Aby system stał się bardziej rozmowny wypijmy z nim po piwku i dodajmy jeszcze opcję -v (verbose) – gadatliwość.

Zobaczmy teraz jak manual definiuje opcję -p: This option will case e2fsck to automatically fix any filesystem problems that can be safely fixed without human intervention.

Ta sama procedura dla reisera:

Manual reiserfsck dla -p: do some light-weight checks. If these checks reveal a corruption or the flag indicating a (possibly fixable) corruption is found set in the superblock, then reiserfsck switches to the fix-fixable mode.

Jak już mówiliśmy, xfs nie jest sprawdzany w ten sposób. Po uruchomieniu xfs_check na partycji z flagą unclean wyświetlana jest prośba o zamontowanie tej partycji, jej odmontowanie i ponowne sprawdzenie. Innymi słowy, przy mount zostaje odtworzona na dysk kronika i znów wszystko gra. Albo i nie. Wtedy zostaje xfs_repair (zobacz dział o xfs na kolejnej stronie).

Czy przy mount zostanie także odtworzona kronika na ext i reiserze? Odpowiedź brzmi tak! Jak widać systemy plików z księgowaniem są twarde i nie dają się tak łatwo uszkodzić.

Kolejne partycje

Wszystkie partycje poza główną nie wymagają z punktu widzenia systemu poważniejszej uwagi. Dlatego o ile w przypadku / w razie nieudanej próby naprawienia przez -p wyświetlona zostanie konsola i prośba o ręczną interwencję (której po lekturze tej strony możesz dokonać!), o tyle w przypadku nienaprawionego przez -p błędu na innej partycji system i tak się uruchomi. Tak to przynajmniej wygląda w systemach opartych o skrypty typu sysvinit.

Co jeszcze jest ważne? To, które partycje zostaną sprawdzone i w jakiej kolejności. Jeśli kiedyś interesowało Cię co oznaczają te cyferki na końcu /etc/fstab, to możesz przeczytać o tym w man fstab (tak pliki konfiguracyjne też posiadają swoje manuale) lub poniżej.

Zobaczmy typowy /etc/fstab:

Jak widać ostatnie pole (szóste) dla partycji / przyjmuje wartość 1, a dla pozostałych 2, chyba że są to wirtualne systemy plików lub dyski wymienne, wtedy mamy 0. Zera nie są w ogóle sprawdzane, 1 sprawdzany jest jako pierwszy, pozostałe jako kolejne równolegle, chyba że znajdują się na tym samym dysku fizycznym.