Miało być coś ode mnie, ale czasu mało. Miałem pisać o tuningu file systemu, część rzeczy jest już dostępna w sieci (np. ten art poniżej). Ostatecznie zdecydowałem się na początek umieścić to co dostępne w sieci (źródła poniżej) a jak będę miał chwilę to rozszerzże ten opis o swoje spostrzeżenia albo w całości napiszę po swojemu. Tymczasem zapoznajcie się z tematem.
Ext3 – wprowadzenie
System plików Ext3 jak sama nazwa wskazuje wywodzi się od systemu plików Ext2. Jego twórca był Stephen Tweedie oraz jego zespół. Stephen Tweedie był jednym z twórców Ext2. Pierwszy sterownik do Ext3 pojawił się w jądrze 2.4.16 . Jego twórcom w czasie pracy nad Ext3 przyświecały dwa cele:- Aby był on jak najbardziej to możliwe kompatybilny ze swoim poprzednikiem Ext2.
- Aby był on nowoczesnym systemem plików z kronikowaniem.
Kompatybilność
Ponieważ Ext2 był bardzo cenionym i lubianym systemem plików przez użytkowników postanowiono, że nowy system plików Ext3 będzie o ile to tylko możliwe podobny do swego poprzednika. W rzeczywistości jeśli do Ext2 dodamy moduł odpowiedzialny za kronikowanie, to system plików możemy zamontować jako Ext3. Kompatybilność ta działa w obydwie strony, czyli Ext3 także możemy zamontować jako Ext2, o ile w system został poprawnie odmontowany i nie doszło do awarii.Ogólna idea kronikowania
Kronikowanie, inaczej nazywane księgowaniem lub dziennikowaniem (ang. journaling) jest to taka funkcja systemu plików, która zapisuje operacje zlecone systemowi plików, ale jeszcze nie dokończone w specjalnym pliku nazywanym dziennikiem (ang. journal). Dzięki dziennikowi system jest w stanie w bardzo krótkim czasie powrócić do stanu spójnego po awarii. Kronikowanie nie zapewnia jednak, że pewne dane nie zostaną utracone. Czas działania naprawy systemu po awarii w przypadku systemów z kronikowaniem nie zależy od wielkości partycji, co jest szczególnie istotne dla dużych dysków. Awaria z punktu widzenia systemu plików może się wydarzyć w dwóch momentach. System plików przechowuje nie tylko informacje o danych w zwykłych plikach, ale także informację o strukturze plików i systemu plików. Te drugie nazywamy metadanymi. Jeśli system ulegnie awarii po zapisaniu zmian do dziennika, a przed zmianami w metadanych to po ponownym uruchomieniu systemów, system w bardzo krótkim czasie (od kilku do kilkunastu sekund ) przejdzie w stan spójności, dzięki informacjom zapisanym w dzienniku.(transakcja pełna) Jeżeli natomiast do awarii dojdzie po modyfikacji danych a przed zapisaniem zmian do dziennika to zmiany te nie są brane pod uwagę przy ponownym uruchamianiu systemu.(transakcja niepełna).Transakcje pozwalają traktować operacje zapisu, tworzenia lub usuwania katalogu w sposób atomowy, które normalnie atomowe nie są. Transakcje działają w sposób analogiczny jak w systemach bazodanowych. Nanoszą one do dziennika pełne operacje.Rozróżniamy dwa podstawowe typy kronikowania:
- tylko metadanych (zapewnia spójność metadanych, ale może nie pamiętać ostatnio wpisanych danych tuż przed awarią)
- metadanych i danych (odtworzy wszystko co zostało w całości wprowadzone do dziennika)
- ReiserFS
- XFS ( o nim mowa później)
- JFS
Co może się wydarzyć w systemie plików bez księgowania?
W przypadku systemów plików bez dziennika (przykładem jest poprzednik Ext3 -system plików Ext2)aby przywrócić spójność po nagłej awarii, trzeba uruchamiać specjalny program poprawiający błędne wpisy. W systemie Ext2 jest to automatycznie uruchamiany program fsck, który przy dużej powierzchni dysków może działać długo, ale bez niego w przypadku pozostawienia błędów w strukturze plików będą się one propagować aż cała partycja może nie nadawać się do użytku.Najczęstsze błędy to:
- może się zdarzyć, że awaria nastąpiła po tym jak plik został już skasowany, a system nie zdążył zwolnić superbloków, które zajmował ten plik. Wiąże się to z utratą pojemności tzn. superblok będzie uważany za zajęty, a pliku już nie będzie
- nie zostaną zaktualizowane pewne liczniki i źle zadziała algorytm przydziału bloków (tzn. awaria nastąpi po skasowaniu lub dodaniu jakiegoś obiektu, ale nie odnotowaniu tej zmiany w systemie)
- adres nowo dodawanego bloku pośredniego może zostać wpisany do i-węzła zanim zostanie zapisany sam blok, w efekcie czego różne pliki mogą używać tych samych bloków. Gdy błędny plik zostanie skasowany, zwolnione (i zamazane) zostaną bloki współdzielone z innymi, dotąd poprawnymi plikami. Błędy tego typu są najpoważniejsze.
Księgowanie w systemie plików ext3
Kronikowanie w systemie plików Ext3, nie jest bezpośrednio zaimplementowane. Wykorzystane jest specjalne API nazywane warstwą Journaling Block Device (JBD). JBD zostało napisane aby w prosty sposób dołączać dziennikowanie do dowolnego urządzenia blokowego.Komunikacja między Ext3 a JBD bazuje na 3 głównych modułach:
- rekordy dziennika (ang. log records) - opisuje pojedynczą operację na bloku dyskowym
- operacji atomowych (ang. atomic operation handle) - jest to zbiór operacji niskopoziomowych, które składają się na jedną operacje wysokiego poziomu
- transakcji (ang. transaction) – składa się na nią kilka operacji atomowych. Transakcja jest reprezentowana przez deskryptor typu transaction_t, którego najważniejszym polem jest t_state. Pole to opisuje obecny status transakcji. Transakcje mogą być pełne lub niepełne. W przypadku transakcji pełnej pole i_state jest ustawione na T_FINISHED. W przypadku transakcji niepełnej możliwe ustawienia pola i_state to T_RUNNING, T_LOCKED, T_FLUSH, T_COMMIT.
Inne systemy plików stosują najczęściej tak zwane dziennikowanie logiczne. Polega ono na tym, że do dziennika są zapisywane tylko zmiany między blokami do zapisania i tymi które są już na dysku.
Różnica ta jest pamiętana jako lista bajtów do zmiany. Przy dokonywaniu transakcji istotną kwestią jest przewidywanie ile bloków może zostać zmodyfikowanych. Jeśli miejsce w dzienniku się kończy transakcje zostają wstrzymane. Dlatego przy każdym rozpoczęciu transakcji, Ext3 musi określić ile maksymalnie bloków może zostać zmodyfikowanych.
Tryby księgowania w ext3
W systemie plików ext3 są dostępne trzy tryby kronikowania. Ich angielskie nazwy to:- journal
- ordered
- writeback
Tryb journal
Jest to najbezpieczniejszy i zarazem najwolniejszy tryb księgowania, który kronikuje zarówno dane jak i metadane. Ten sposób księgowania minimalizuje szanse strat modyfikowanych danych w plikach, ale wymaga wielu operacji dyskowych np. kiedy nowy plik jest tworzony, wszystkie jego bloki z danymi muszą być podwójnie zapisane w dzienniku.Tryb writeback
Jest to tryb najczęściej występujący w innych systemach plików. Jest także najczęściej stosowanym trybem w systemie plików Ext3. Księgowane są tu jedynie zmiany w metadanych. Choć gwarantuje to spójność systemu plików, na końcu plików zapisywanych przed awarią mogą pojawić się niepoprawne dane. Jest to najszybszy tryb księgowania w systemie Ext3.Tryb ordered
Tryb ten jest trybem domyślnym. Do dziennika są zapisywane jedynie metadane. Operacje zapisu danych i metadanych układane są w transakcje, kiedy przyjdzie czas na zapisanie nowych metadanych, najpierw zapisywane są dane, a później metadane. Dzięki temu, że metadane są zapisywane na dysk dopiero po zakończeniu operacji zapisu danych, nie jest możliwe by metadane wskazywały na niezapisane jeszcze na dysku dane. Jest to tryb szybszy niż pełne kronikowanie.Aby nie dochodziło do błędów tryb ordered musi korzystać z następujących technik:
- Revoke Records - specjalne rekordy zapisywane do dziennika. Umożliwiają pominięcie odtwarzania wskazanych bloków z wcześniejszych transakcji. Używane są po skasowaniu metadanych (np. katalogu), aby modyfikacje już nieistniejących struktur nie zamazały nowych bloków pliku.
- nie przydziela na dane tych bloków, które zostały zwolnione, ale operacja ta nie została jeszcze zatwierdzona w dzienniku. Uniemożliwia to zamazanie bloków jednego pliku przez drugi, w przypadku gdy jeszcze możliwe jest powrócenie do danych starego pliku.
- Prowadzenie listy „osieroconych” plików. Jest to specjalna lista plików usuniętych z katalogu, ale otwartych przez procesy. Gdyby w takim momencie przerwać działanie systemu, nie można by ich ani usunąć, ani odzyskać. Dlatego wszystkie takie pliki trzymane są na liście (wskazywanej z superbloku).
Indeksowanie katalogów
Sporą różnicą między Ext2 a Ext3 jest możliwość indeksowania katalogów. W Ext2 wpisy w katalogu są przechowywane na liście liniowej. W Ext3 natomiast po włączeniu funkcji hashed trees katalogi mają postać drzewa. Funkcja ta jest bardzo użyteczna, gdy w katalogach jest dużo plików. Zapewnia to niezwykle szybki dostęp do szukanego w katalogu pliku. W Ext3 zaimplementowane jest indeksowanie jednopoziomowe co pozwala na utrzymanie około 90000 wpisów. Do odnajdywania pliku w katalogu służy specjalna funkcja haszująca. Po jej wyliczeniu łatwo już odnajdujemy szukany blok w czasie logarytmicznym co do wielkości drzewa katalogu. Przy dodawaniu nowej pozycji (przepełnienie bloku z wpisami) stosuje się sortowanie wpisów i podział na dwa bloki. Następnie poprawiane są wpisy w indeksach.Zerowanie wskaźników
W przeciwieństwie do Ext2, Ext3 zeruje wskaźniki do węzłów usuniętych plików. Konsekwencją tego jest to, iż bardzo trudno odnaleźć usunięte pliki.Fragmentacja bloków.
System ext3 może podzielić jeden blok na kawałki o tym samym rozmiarze i w każdym z nich przechowywać małe pliki. Pozwala to znacznie zmniejszyć obszar zajmowany przez dane, gdy w systemie jest wiele małych plików.Inne informacje:
- wielkość pliku do 4 TB
- od wersji z listopada 2004 roku Ext3 ma możliwość rozbudowywania bez konieczności odmontowywania
- Ext2 i Ext3 używają identycznych metadanych
- mała wydajność w przypadku operacji na katalogach z dużą ilością plików, a ponadto jest to wciąż system plikowy w wersji eksperymentalnej
Jedna z metod przyspieszenia systemu plików
Użycie trybu kronikowania: writeback- Tworzymy kopię pliku /etc/fstab
sudo cp /etc/fstab /etc/fstab.bak- Modyfikujemy odpowiedni wpis w pliku /etc/fstab. UWAGA: kolejność dysków może się różnić!
.... #Entry for /dev/sda2 : UUID=3fb44cc5-b09e-4ee9-a658-61b97c8b4f74 / ext3 defaults,errors=remount-ro,data=writeback 0 1- Edytujemy plik /boot/grub/menu.lst i na końcu następujących linii dodajemy wpis: rootflags=data=writeback:
# defoptions=quiet splash locale=pl_PL vga=791 resume=/dev/sda7 rootflags=data=writeback # altoptions=(recovery mode) single rootflags=data=writebackDodane flagi, będą automatycznie dodawane do linii jądra systemu i pozostaną tam nawet po uaktualnieniu jądra.
- Uaktualniamy gruba
sudo update-grub- I na koniec modyfikujemy naszą kronikę do trybu writeback. UWAGA: kolejność dysków może się różnić!
sudo tune2fs -o journal_data_writeback /dev/sda2Aby sprawdzić czy nasz system plików posiada kronikę, wpisz:
sudo tune2fs -l /dev/sda2 | grep features Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_filePo takich zmianach, system będzie odczuwalnie działał szybciej. Jednak nie ma róży bez kolcy, a cena jaką możemy ponieść to:
Pomimo iż jest to najszybszy tryb księgowania w systemie Ext3 to księgowane są tu jedynie zmiany w metadanych. Choć gwarantuje to spójność systemu plików, na końcu plików zapisywanych przed awarią mogą pojawić się niepoprawne dane.
Teraz bezpiecznie uruchamiamy ponownie nasz system.
NOATIME - nie zapisujemy czasu dostępu do plików
To kolejna z możliwości tuningu systemu plików- Tworzymy kopię pliku /etc/fstab
sudo cp /etc/fstab /etc/fstab.bak- Modyfikujemy odpowiedni wpis w pliku /etc/fstab. UWAGA: kolejność dysków może się różnić!
/dev/hda1 / ext3 defaults,errors=remount-ro,noatime,auto,rw,dev,exec,suid,nouser,data=writeback 0 1Jedyną wada jest fakt, że nie będziemy mogli skorzystać z wyszukiwania plików poleceniem find, według daty dostępu.
Nieco mniej ryzykowne rozwiązanie prezentuję poniżej.
Wyłączenie "atime" rekursywnie dla wybranych katalogów i plików:
Kiedy Linux odczytuje plik, zmieniana jest ostatnia data dostępu do tego pliku, zwana jako "atime".Może to być uciążliwe jeśli korzystasz np.: z serwera www, a zapytania do twojego serwera są rzędu 50 zapytań / sekundę. Wówczas Twój system uaktualnia 50 razy rekord "atime" w ciągu 1 sekundy. Czy w przypadku serwera www jest to faktycznie niezbędne? Czy musisz widzieć kiedy był ostatni dostęp do pliku? Jeśli nie, możesz wyłączyć opcję "atime" dla konkretnego katalogu. W tym celu wpisz w konsoli:
sudo chattr -R +A /var/www/popularna_strona/Powyższe polecenie powie systemowi plików, aby nie uaktualniał rekordu "atime" (opcja +A) dla całej zawartości podanego katalogu (opcja -R oznacza rekursywnie) oraz plików w nim zawartych.
tune2fs - dostrajanie parametrów systemu plików ext2/ext3
Zmianę częstotliwości wykonywania obowiązkowego sprawdzenia partycji, możemy wykonać stosując polecenie tune2fs.Domyślnie częstość sprawdzania ustawiona jest co 30 montowań partycji. Aby zmienić tę wartość na np.: co 60 montowań, wykonaj:
sudo tune2fs -c 60Można również wybrać opcję kontroli cotygodniowych:
sudo tune2fs -i 1wlub analogicznie comiesięcznych:
sudo tune2fs -i 1mZa pomocą tego samego programu, możliwe jest również nadanie etykiety partycji, tzw. LABEL. Aby to zrobić należy wykonać:
sudo tune2fs -L etykieta /dev/sdaXOraz zobaczyć szczegóły dotyczące naszego systemu plików na danej partycji:
sudo tune2fs -l /dev/sda2
tune2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: ubuntu-ff
Last mounted on:
Filesystem UUID: 3fb44cc5-b09e-4ee9-a658-61b97c8b4f74
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1913184
Block count: 3823470
Reserved block count: 191173
Free blocks: 2780622
Free inodes: 1729521
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 933
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16352
Inode blocks per group: 511
Filesystem created: Sat Apr 21 02:44:26 2007
Last mount time: Fri Apr 27 22:19:19 2007
Last write time: Fri Apr 27 22:19:19 2007
Mount count: 25
Maximum mount count: 35
Last checked: Sat Apr 21 01:22:07 2007
Check interval: 15552000 (6 months)
Next check after: Thu Oct 18 01:22:07 2007
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: a73f081c-50e9-4c1e-88eb-aaca3453afe0
Journal backup: inode blocks
Źródło, Źródło 2
Brak komentarzy:
Prześlij komentarz