Lokalne systemy plików

1. Wstęp

Tematem nimniejszego dokumentu są lokalne systemy plików. W dalszej części będziemy po kolei opisywać różne znane systemy plików. Nasze opisy nie dostarczą dość informacji, by napisać własną implementację, a jedynie by zrozumieć główne rozwiązania danego systemu. Pozwoli nam to ocenić różnice danych systemów, ich wady i zalety.

1.1. Zagadnienia związane z systemami plików

Przed twórcą systemu plików stoi wiele wyzwań:

• Musi on zaplanować gdzie i jak będą przechowywane parametry nośnika.
• Trzeba zaprojektować baze plików dyskowych, określić ich atrybuty i funkcje.
• Powinien stworzyć wydajny alokator bloków dyskowych.
• System powinien minimalizować czas operacji dyskowych.
• System powinien w miarę możliwości być odporny na awarie i uszkodzenia.

Dwa pierwsze punkty dotyczą dodatkowych danych jakie będzą obsługiwane w danym systemie plików. Część z nich jest niezbędna samej implementacji, na przykład parametry dysku czy wielkości jednostek alokacji. Większość jednak potrzebna jest użytkownikowi. Słabości tej części są przyczynami wielu komplikacji w przyszłości. Przykładem może być problem z dostarczeniem długich do nazw plików w systemie „Windows 95” , lub brak list praw dostępu w „ext2”

W ewolucji systemów pliów daje się zauważyć zmiane warzności poszczgólnych cech systemu dla projektanta. Początkowo od wygody urzytkownika warzniejsza była prostota implementacji. Systemy optymalizowano by dostarczały jak najwięcej przestrzeni dla danych często kosztem wydajności. Z czasem jak nośniki stawały się tańsze daje się zauwarzyć wzrost nakładów na wydajność. Dopiero ostatnio twórcy są gotowi rezygnować z wydajność na korzyść bezpieczeństwa.

Z przedstawionych powyrzej zwgledów ocena jakości systemu pliku nie może być jednoznaczna. Jak zobaczymy dalej mniej wydajne systemy będą zwykle miały albo mniejszą fragmentacje wewnętrzna albo większe bezpieczeństwo.

1.2. Pojęcia

Dalej bedziemy posługiwać się następującymi pojęciami:

blok dyskowy

Jednostka transmisji z urządzeniem blokowym

klaster

Grupa bloków dyskowych używana jako jednostka alkocji

2. Filesytem FAT

„FAT” był jedynym systemem plików w systemie „DOS” . Podobno początkowo nie posiadał nawet podkatalogów. W miarę współczesny wygląd uzyskał dopiero w „DOS 2.0” .

2.1. Organizacja dysku

Dysk w systemie „DOS” podzielony jest na partycje. Przykład takiego podzału widać na rysunku 2.1.1. Pierwszy sektor dysku nazywa się „Master Boot Sector” w skrócie „MBR” . Pod koniec tego sektora znajduje się opis podziału dysku na strefy, tak zwana tablica partycji. Budowę tablicy partycji przedstawia tabela 2.1.2

Strefa rozszerzona definiuje dysk logiczny. Strefa taka ma strukturę dokładnie taką samą jak dysk i posiada własną tablicę partycji.

Strefa z systemem plików zamiast tablicy partycji posiada rekord ładujacy, którego zawartość opisuje parametry dysku i strefy. (patrz tabela 2.1.3). Bajty 11-23 definują bloki parametrów BIOS (BPB).

2.2. Tablica rozmieszczenia plików

Jednostką alokacji jest klaster, który składa się z całkowitej liczby bloków dyskowych.

„File Allocation Table” jest strukturą opisującą zarówno kolejność klastrów w plikach, jak i wolne klastry. Początkowo była to tablica liczb 12-bitowych, czyli dwa elementy mieściły się w dwóch bajtach. Później wraz ze wzrostem rozmiarów dysków wprowadzono tam liczby 16- i 32-bitowe.

Libczba znajdująca się w tablicy FAT12 miała następujące znaczenie:

0x000	Indeks w tablicy jest numerem wolnego klastra
0xFF7	Dany klaster jest uszkodzony i nie powinien być alokowany
0xFF8-0xFFF	Oznacza że dany klaster jest ostatnim klastrem pliku do którego należy
inny	Jest numerem następnego klastra pliku, do którego należy nasz blok.

W wersji 16-bitowej 0x000 stało się 0x0000, 0xFF7 stało się 0xFFF7, idt. Analogicznie dla wersji 32-bitowej 0x000 stało się 0x00000000, 0xFF7 stało się 0xFFFFFFF7, 0xFF8 przeszło na 0xFFFFFFF8, itd.

Na rysunku 2.2.1 pokazany jest fragment przykładowego FAT. Zostały tam zaznaczone wpisy pliku zaczynającego się od klastra 0x025, a kończącego się na klastrze 0x023.

Fakty:

• FAT opsuje równocześnie wolne bloki, jak i połączenia miedzy nimi.
• Dostęp do danych jest szybszy niż w implementacji plików jako listy bloków.
• Wszystkie inforamcje o powiązaniach bloków są w jednym miejscu. Uszkodzenie FAT powoduje trudne do odwrócenia zmiany. Dlatego na dysku jest zwykle kilka kopi FAT.

2.3. Katalog

Katalog jest zwykłą tablicą rekordów zgodnych z tabelką. 2.3.1

Bity atrybutów:

0

Plik tylko do odczytu (readonly)

1

Plik ukryty (hidden)

2

Plik systemowy

3

Etykieta dysku

4

Podkatalog

5

Plik archiwizowalny

6,7

Nie wykorzystywane

Pierwszy znak nazwy pliku ma szczególne znaczenie:

0x00

Wpis pusty

0xE5

Wpis skasowanego rekordu może być nadpisany przy tworzeniu nowego pliku

0x05

Jako że 0xE5 jest dopuszczalnym znakiem nazwy pliku, to nie może wystąpić jawnie -- zamiast tego umieszczany jest kod 0x05

0x2E

Jest to znak kropki, jeśli następnym bajtem jest też kropka, to jest to wpis wskaźnika do katalogu rodzica. Dla katologu głównego adres ten jest równy 0.

Wraz z pojawieniem się „Windows 95” , FAT zyskał długie nazwy plików. Odbyło się to przy zachowaniu kompatybilności z systemem DOS. Wykorzystano fakt, że nie wyświetla się wpisów etykiet dysku z wyjątkiem pierwszego takiego wpisu w katalogu głównym.

Własności wpisu długiej nazwy:

• Pole atrybut ma wszystkie bity ustawione na 1. W normalnym DOS-ie tak nigdy nie jest.
• Numer pierwszego JAP pliku wsakazuje na 0.
• Rekord ten poprzedza właściwy wpis z krótką nazwą.
• Nazwa zapisana jest w 16-bitowym unikodzie.

Jak widać w rekordzie może być maksymalnie 13 liter. Nie używane litery ustawia się na 0.

Dodatkowych wyjaśnień wymaga pole „ID” .

• bity 0-5 to numer sekwencyjny rekordu dla danego wpisu.
• bit 6 to znacznik ostatniego bloku.
• bit 7 to znaczink usunięcia

3. Od SytemV do Ext3

3.1. SystemV

Budowa dysku jest bardzo prosta:

Bloki i-węzłów to tablica stałej wielkości rekordów opisujących i-węzeł. Przestrzeń ta ma stałą wielkość, czyli dana jest z góry określona maksymalna liczba plików. Ta zła własność została zachowana i chrakteryzuje również system „ext3” .

Alokacja i-węzłów

Jest bardzo prosta. Korzysta się tu ze zoptymalizowanego przeszukiwania liniowego. Ulepszenie polega na tym, że w superbloku znajduje się tablica numerów wolnych i-węzłów.

• Ostatnim elementem listy w superbloku powinien być wolny węzeł o najmniejszym numerze nie występującym w liście.
• Dopóki tablica jest niepusta, numery i-węzłów pobiera się z listy w superbloku.
• Gdy lista w superbloku jest pusta, przechodzi się ją zaczynając od pozycji na jaką wskazywał ostatnio zaalokowany blok (bo wcześniejsze powinny być zajęte zgodnie z własnością podaną powyżej) i umieszcza się w liście wolne indeksy aż do zapełnienia listy.

Zastosowany algorytm był wystarczająco wydajny. Alokacje i-węzłów są stosunkowo rzadkie w porównaniu z alokacjami bloków dyskowych. Kosztowna operacja uzupełniania listy wykonywana jest rzadko i w praktyce wykonuje się szybciej niż w pesymistycznym przypadku, ponieważ węzły alokowane w tym samym czasie zazwyczaj są również zwalniane w bliskich odcinkach czasu.

Alokacja bloków

Do zarządzania wolnymi blokami używa się list wolnych bloków. Początek listy znajduje się w superbloku. Każdy węzeł listy zawiera tablice wolnych bloków ze wskaźnikiem na wolny blok zawierający następny węzeł.

Na przedstawionym przykładzie kolejne alokacje będą dawać bloki: 420, 508, ..., 165, 205, 101, 100, ...

Alokacja bloku 100 przebiega w spoób wyjątkowy, ponieważ blok ten jest następnikiem superbloku w liście i nie może być on natychmiastowo użyty. Najpierw jego zawartość zostaje przekopiowana w miejsce pustej tablicy w superbloku (patrz rysunek).

Zwalnianie bloku polega na dopisaniu bloku na koniec tablicy znajdującej się w superbloku. Jeśli tablica jest pełna i nastąpi zwolnienie bloku, powiedzmy numer 291, to zawartość superbloku zostanie skopiowana do bloku 291, a tablica wolnych bloków będzie posiadać teraz tylko jeden wpis 291.

Alokator ten jest stosunkowo szybki, ma jednak bardzo poważną wadę: bloki w liście nie są ułożone w żaden rozsądny sposób, przez co pliki ulegają wysokiej fragmentacji.

Struktura i-węzła

Adresowanie bloków w i-węźle przebiega przez strukture teblicową.

• 10 adresów bezpośrednich
• 1 adres pojedyńczo pośredni
• 1 adres podwójnie pośredni
• 1 adres potrójnie pośredni

Standardowe bloki miały po 1kb.

3.2. Minix

„Linux” pisany był pod systemem „Minix” i początkowo jako swój system plików używał systemu z Minix-a. System ten jest podobny do SystemV. Podobnie jak on, ma z góry ustaloną liczbę i-węzłów. Dodatkowo nie posiada bloków potrójnie pośrednich, ponieważ bloki numerowane są liczbami 16-bitowymi, dzieki czemu w bloku pośrednim mieści się 512 adesów. Pozwala to zmniejszyć liczbę bloków adresujących.

Wprowadzanie map bitowych przyśpiesza alokację, ponieważ mapy są dostatecznie małe, by móc przechowywać je w pamięci. Mapy ułatwiają również walkę z fragmentacją.

Wpisy katalogowe były stałej wiekości, ustalonej z góry i zapisanej w superbloku.

Własności:

• 16 bitowe adresowanie
• mapy bitowe do alokacji i-węzłow i bloków danych
• 7 adresów bezpośrednich
• brak adresowanie potrójnie pośredniego
• maksymalna wielkość dysku 64MB dla bloków 1kb
• standardowo nazwa ma maksymalnie 14 znaków
• jednostką alokacji jest grupa bloków. Dla bloków 4kb używanych dla dysków twardych w linux'ie maksymalna wielkość dysku wynosiła 256MB.

Implementacja Minix-a z jądra 1.0 rozpatrywała adresowanie takie, jak przy SystemV (32-bitowe adresowanie z odwołaniem potrójnie pośrednim).

3.3. ext2

Ograniczenia Minix-a spowodowały, że rozpoczęto prace nad jego modyfikacjami. Jedną z nich, choć nie jedyną, była implementacja systemu „ext2” , który rozwiązuje większość problemów z Minix-a. Posiada zmienną wielkość wpisu w strukturze katalogu, dzięki czemu nie występuje problem z długimi nazwami. Jedynym ograniczeniem jest to, że wpis musi się mieścić w pojedyńczym bloku dyskowym.

W opisie grupy znajdują się informacje o pozycjach dyskowych pozostałych elementów grupy.

Większość informacji o tym systemie plików była podana na wykładzie, dlatego nie będę tu przedstawiać więcej detali. Zamiast tego omówię niektóre rozszerzenia tego systemu.

Indeksy katalogów

Standardowa implementacja ext2 używa katalogów w postaci niezindeksowanej. Przez co koszt n wstawień do katalogu wynosi O(n^2)

Rozpoczęto, i zadaje się że nadal trwa, wiele projektów których celem jest dodanie B-drzew do ext2. Z dostępnych rozwiązań interesująca wydaje się implementacja indeksowanych katalogów wykonana przez Daniela Phillipsa.

• Korzysta się z prostszej od B-drzew struktury danych, przez autora nazwanej HTree.
• Zapisy w strukturze katalogowej są zgodne ze standardowym zapisem ext2. Różnica polego na dodaniu na początku jednego bloku jako korzenia struktury indeksowej.

HTree

• Liśćmi są bloki ze zwykłymi wpisami katalogowymi.
• Korzeń jest pierwszym blokiem katalogu
• Kluczem drzewa jest klucz mieszający (hash) nazwy pliku
• Węzły wewnętrzne drzewa zawierają posortowaną tablice par (hash, blok). Gdzie hash jest dolnym ograniczeniem z wartość hash-a w liściu, a blok jest wskaźnikiem do dziecka.
• Najmłodszy bit wartości hash ma specjalne znaczenie i oznacza że nastąpiła kolizja.
• Wpisy hash i blok są 32-bitowte

Operacja wyszukiwania:

• Sprawdzana jest poprawność korzenia. Jeśli jest on uszkodzony, stosuje się klasyczne wyszukiwanie liniowe.
• Oblicza się wartość klucza (hash)
• Zaczynając od korzenia schodzi się w dół drzewa, za każdym razem wyszukując binarnie wpis z dolną granicą mniejszą lub równą szukanemu kluczowi i następnikiem z większym od klucza.
• Odczytany w końcu blok liści przeszukuje się liniowo.
• Jeśli nazwa nie została odnaleziona, trzeba sprawdzić czy nie nastąpiła kolizja. Wykonuje się to patrząc do ojca czy następnik nie ma bitu kolizji. Jeśli dany blok był ostatnim we wpisie u ojca, bierze się pierwszy wpis w następniku ojca.
• Sprawdza się, czy klucz pasuje do wartości hash z odjętym bitem kolizji (to znaczy czy jest od niego mniejszy). Jeśli tak, to wykonuje się sprawdzenie zgodnie z wcześniejszum schematem.
• Gdy nie ma kolizji lub nie ma następnika, szukanie można zakończyć porażką.

W praktyce kolizje zdarzają się wyjątkowo rzadko.

Operacja dodawania nazwy jest stosunkowo prosta. Najpierw znajduje się blok, w którym nazwa mogła by występować, zgodnie z tym co jest napisane powyżej. Jeśli w bloku jest wolne miejsce, to można od razu dodać nowy wpis.

Jeśli brakuje miejsca, trzeba wykonać podział bloku tak, jak ma to miejsce przy zwykłych B-drzewach.

• Dla ułatwienia wpisy w bloku sortuje się według wartości klucza mieszającego.
• Następnie trzeba przenieść górną część wpisów katalogowych do nowego bloku. W aktualnej implementacji przenosi się połowę wpisów w sensie ich kolejności w bloku.
• Najmniejszy hash z górnego podziału idzie do ojca. Jeśli podział spowodował że wpisy o tym samym hash-u są w różnych blokach, zaznaczany jest bit kolizji.
• Jeśli w ojcu nie ma miejsca to dokonyje się jego podziału na poł, i w tak samo minimum z górnej połówki idzie do ojca. Jeśli podział dotyczy korzenia to tworzy się nową warstwe.

Journaling

ext2 z journalingiem nazywany jest ext3. W przciwieństwie do innych implementacji systemu plików z tranzakcjami oprócz journalingu metadanych posiada on możliwość logowania zmian bloków.

Szczegóły tego rozszerzenia są omówione w następnym rozdziale.

4. EXT3 i JBD

W rozdziale tym zostanie omówiona architektura systemu plików „ext3” . Zostaną omówione co ciekawsze detale szegóły z implementacji, których celem będzie nauczenie metod stosowania i implementacji „journalingu” we własnych aplikacjach.

4.1. Własności transakcji

Dyskusje zaczniemy od tego czym są transakcje. Sama koncepcja pochodzi z baz danych, w których ważne okazało się zachowanie spójności danych w trakcie złożonych operacji.

Często jako przykład użyteczności transakcji podaje się system bankowy. Na rysunku 4.1.1 podany został bardzo prosty przykład sytuacji gdy brak synchronizacji prowadzi do błędów.

Podstawowe własności transakcji to:

Atomowość

Transakcja wykonuje się w całości lub wcale.

Spójność

Po wykonaniu stan systemu spełnia więzy spójności. Dane tworzą poprawną całość.

Izolacja

Inne wykonywane transakcje nie mają wpływu na siebie.

Trwałość

Zatwierdzona transakcja zostanie wykonana na trwałe i jej wynik nie zostanie utracony.

Systemy plików są bardzo szczególnym rodzajem baz danych. Transakcje wykonywane w typowych systemach plików są łatwiejsze w implementacji niż w ogólnym bazodanowym przypadku.

Od systemu z transakcjami oczekujemy że po nagłej awarii i ponownym uruchomieniu system znajdzie się poprawnym z punktu widzenia jego budowy stanie. Oczekujemy że każda rozpoczęta transakcja albo będzie całkowicie zakończona albo całkowicie anulowana.

Na przykład gdy kasujemy plik mogą być wykonywane następujące operacje:

1. Szuka się wpisu pliku w strukturze katalogowej
2. Pobiera się numer i-węzła we wpisie.
3. Z bloku z wpisem usuwa się znaleziony rekord
4. Odczytuje się blok z opisem i-węzła. Zmniejszamy i sprawdzamy licznik referencji.
5. Jeśli licznik referencji w i-węźle jest 0 oraz żaden proces nie ma do niego referencji (dodatkowy licznik z VFS). To zwalniamy zaalokowane bloki. Wymaga to szeregu odczytów struktury indeksowej i modyfikacji szeregu bloków w mapie bitowej wolnych bloków.

Teraz jeśli awaria nastąpi w punkcie 4 zanim zapiszemy blok ze zmniejszonym licznikiem. Na dysku będą znajdować się zaalokowane bloki do których nie będzie żadnej referencji. By móc stwierdzić że wartość licznika i i-węźle jest fałszywa trzeba przejrzeć wszystkie wpisy katalogowe. Gdyby awaria nastąpiła nastąpiła podczas zwalniania bloków, to by dokończyć tą operacje trzeba przejrzeć wszystkie struktury indeksowe. Tym samym widać że w standardowym systemie plików start systemu po awarii łączy się z pełną rekonstrukcją wszystkich metadanych.

Głównym celem wprowadzenia journalingu jest uzyskanie atomowości tego typu operacji.

4.2. Transakcja w systemach plików

Systemy plików charakteryzują następujące własności:

• Transakcje trwają stosunkowo krótko
• Właściwie nie ma anulowania transakcji
• Można ograniczyć się tylko do metadanych. Sementyka unix'a pozwala na opóźnione zapisywanie zmian. W przypadkach gdy natychmiastowy zapis jest ważny dla aplikacji, powinna ona otwierać dostęp w trybie synchronicznym

W systemie „ext3” podstawową operacją jest zapis bloku. Pojedyncza transakcje jest tu sekwencją operacji zapisu określonych danych w określonym miejscu. Takie podejście powoduje że:

• Strategia taka jest prosta w implementacji
• Operacje takie mają własność redo. By dokończyć zamieszczoną w logu przed awarią transakcje wystarczy ją powtórzyć. (nie trzeba pamiętać stanu przed transakcją)
• Funkcje obsługi logów mogą być niezależne od struktury systemu plików (nie ma znaczenia czego dotyczą dane znajdujące się w zleceniach).
• Można tanio łączyć transakcje ze sobą. Robi się to umieszczając operacje z obu transakcji. Jeśli dane operacje dotyczą tego samego bloku to umieszcza się tylko najmłodszą. (w praktyce oznacza to tyle że dopóki nie chcemy rozdzielać transakcji trzymamy tylko jedną kopie bloku urządzenia blokowego).

Ostatni punkt jest bardzo ważną i wydajną optymalizacją.

4.3. JBD

Obsługa journalingu została wyjęta do oddzielnego modułu Journaling Block Device (JBD).

Pojęcia

Punkt kontrolny

Tranaskcje są łączone w grupy. Zmknięcie grupy nazywany punktem kontrolnym

Deskryptor punktu kontrolnego

Opis, w logu, operacji jakie należy wykonać by system plików osiągnoł punkt kontrolny. By wykonać te operacje trzeba jeszcze mieć zawartość bloków danych.

Typy danych

journal_t

Opisuje całkowity stan danego logu. Zarządza rozmieszczeniem deskryptorów transakcji w logu, oraz synchronizacją z dyskiem.

handle_t

Znacznik tworzonej transakcji. Operacje wykonywane zostaną wykonane w całości lub wcale. Mogą się one wykonać tylko wtedy gdy operacje starszych znaczników też zostały wykonane.

Funkcje

Funkcje te zakładają log odpowiednio na: spójnym obszarze urządzenia blokowego, w podanym i-węźle

Zapisuje wszystkie dane do logu i na dysk. Używane przy przemontowywaniu w tryb tylko do odczytu.

Blokuje wszystkie przyszłe tranzakcje w chwili rozpoczęcia. Blokuje do chwili aż aktualnie trwające tranzakcje się nie zakończą.

Zdejmuje blokadę na nowe tranzakcje

Tworzy nowy log.

Inicjuje struktury danych dla istniejącego już logu

Zwalnia strukturę. Przeciwieństwo „init”

Wznawia log po awarii. Najpierw znajduje się deskryptor transakcji o najnowszym numerze. Następnie

Rozpoczyna nową tranzakcje. Wartość „nblocks” określa ile maksymalnie bloków będzie modyfikować. Funkcja „journal_start” czeka aż w logu będzie dostatecznie dużo wolnego miejsca

Pozwala w tym samym znaczniku otworzyć nową tranzakcje

Próbuje zwiększyć maksymalną liczbe modyfikowanych bloków. Ponieważ nie ma anulowania transakcji trzeba sobie poradzić nawet wtedy gdyby zwiększenie byłoby niemożliwe

Poinformowanie że będziemy pisać do danego bufora. Zgodnie z tym co było mówione jeśli ta tranzakcje łączona jest z inną nie trzeba nic robić. Natomiast jeśli rozpoczęto zapis lub realizacje transakcji z użyciem danego bufora to trzeba wykonać kopie roboczą.

Poinformowanie o dostępie do nowego bloku. Sprawdza się czy bufor jest używany przez inną tranzakcje (to się nie powinno zdarzyć).

Poinformowanie o zwolnieniu bufora. Dzieki temu nie trzba trzymać jego kopii.

Dodanie do transakcji operacji modyfikacji bloku. Podczas zapisu bufor zostanie umieszczony w logu. „Linux” pozwala na efektywne zpisywanie bufora w innym miejscu niż docelowe. Robi się to tworząć nowy nagłówek bufora z innym adresem ale tym samym wskaźnikiem do danych.

To co wyżej tylko dla metadanych. „ext3” może pracować w różnych trybach. Journaling danych jest opcjonalny, efektywniej jest zapisywać tylko metadane. Jest ich mniej więc tranzakcje na nich lepiej się łączą w gupy.

Zamknięcie tranzakcji. Nie jest ona wykonywana natychmiast (może że jest ustawiony tryb synchroniczny), przez co może być łączona z kolejną.

Algorytm journal_commit_transation

Celem jest zsynchronizowanie listy operacji z logiem. Funkcja wołana jest z demona synchronizującego „kjournald”

1. Blokujemy otwieranie nowych transakcji
2. Czekamy na zakończenie trwających transakcji
3. Synchronizujeny super blok logu. Zapisując nowy numer ostatniej transakcji, oraz kod błędu zapamientany w journal_t.
4. Kasujemy bufory zapisanych punktów kontrolnych.
5. Zapisujemy bloki danych
6. Zapisujemy metadane logu
7. Zapisujemy znacznik końca transakcji

Później funkcja „log_do_checkpoint” może nas doprowadzić do stanu w którym bufory znajdą się we właściwych miejscach. Działanie polega na wykonywani operacji z listy.

Etapy zapisywania danych

By zakończyć transakcje trzeba przejść następujące etapy:

1. Zamykamy tranzakcje od tego momentu wszystkie operacje są w nowej tranzakcji.
2. Wątek zapisu do logu sprowadza transakcje na dysk.
3. Czekamy aż czekające na wykonanie zmiany zostaną zapisane w logu.
4. Zapisujemy nowe wartości nagłówków logu
5. Następnie gdy bloki są synchronizowane z właściwymi miejscami na dysku (dopiero gdy jest to konieczne). Nagrane bloki są zanaczane jako wolne. Gdy cały checkpoint zostanie osiągnięty to zajmowane przez niego miejsce w logu może być zwolnione

4.4. Podsumowanie

• ext3 w przeciwieństwie do innych systemów pozwala na logowanie zarówno metadanych jak i samych danych.
• Obsługa logu jest zamknięta w oddzielnym module. I pozwala napisać obsługę logu do dowolnego istniejącego systemu plików np. FAT
• Pojedynczy log może dotyczyć kilku systemów plików.