Jest to rozszerzenie do standardowego systemu plików Ext2, dodające do niego journalling. Ext3 został stworzony przez zespół dr Stephena Tweedie, jednego z twórców Ext2.
Podczas używania standardowych systemów plików takich jak Ext2 mogą pojawić się problemy po nagłym wyłączeniu komputera. Może się zdarzyć, że system operacyjny przestanie działać w trakcie wykonywania pewnych operacji na dysku, pozostawiając system plików w niespójnym stanie. Może się to objawiać m.in:
Aby temu przeciwdziałać, w systemie Ext2 używa się flagi mówiącej o tym, czy system został poprawnie zamknięty. Jeśli nie, wymuszane jest uruchomienie programu fsck, który znajduje i naprawia wszelkie niezgodności w badanym systemie plików.
Nie jest to jednak rozwiązanie idealne:
Rozwiązaniem tych problemów jest stosowanie journala, w którym zapisywane są wszystkie przeprowadzane, ale jeszcze nie zakończone, operacje. Przy uruchamianiu systemu, dane z dziennika zostają użyte do przywrócenia spójnego stanu systemu plików. (Ale: journalling nie zapewnia, że dane zapisane przed awarią trafią na dysk, a jedynie to, że nie będzie w nich błędów).
System plików Ext3 jest oparty na Ext2, i, poza dodanym journallingiem, nie różni się od oryginału prawie niczym. Zgodność ta posunięta jest do tego stopnia, że poprawnie odmontowaną partycję Ext3 można zamontować jako Ext2 (i odwrotnie).
Ext3 przeznacza pewien obszar dysku na plik dziennika. Wszelkie zmiany metadanych na partycji są najpierw zapisywane do dziennika, a dopiero potem na dysk. Jeśli nastąpi awaria, to podczas przeładowywania systemu wszystkie kompletne zmiany zapamiętane w dzienniku zostają zapisane na dysku, zaś zmiany, które nie zostały w całości zapisane do dziennika zostają zignorowane (gdyż z pewnością nie trafiły jeszcze na dysk).
Dodatkową zaletą Ext3 jest to, że journal może być zapisany jako zwyczajny plik (widoczny w głównym katalogu partycji).
Podstawową wadą tak Ext3, jak i innych systemów z journallingiem, jest teoretycznie mniejsza wydajność (te same informacje muszą zostać zapisane dwa razy). Okazuje się jednak, że w typowych zastosowaniach nie ma to negatywnego wpływu na wydajność.
System plików Ext3 korzysta ze specjalnie stworzonego modułu JBD (Journal Block Device). Moduł ten zawiera implementację transakcyjności. Jest przy tym na tyle ogólny, że może być używany także do innych zadań, nie tylko obsługi journallingu systemu plików.
Zmiany w Ext3 w stosunku do Ext2 składają się głównie z wyznaczenia granic transakcji poprzez odpowiednie wywołania JBD.
Dziennik dla systemu plików Ext3 może być umieszczony wewnątrz samego systemu (jako zwykły plik), lub na innej partycji.
Do dziennika zapisywane są kompletne zmienione bloki, które mają być zapisane na dysk. Rozwiązanie to zwiększa co prawda rozmiar dziennika i ilość zapisywanych danych, ale jest prostsze do zaimplementowania i wymaga mniej czasu procesora niż zapisywanie tylko zmienionych fragmentów bloków. JBD oznacza transakcję za zakończoną poprzez zapisanie w dzienniku bloku zawierającego specjalne sekwencje - korzysta przy tym z założenia, że dysk zawsze skończy zapisywanie pojedynczego sektora (używając własnego zapasu energii).
Istnienie pustego pliku dziennika jest rozszerzeniem "kompatybilnym" systemu Ext2 (tzn. zostaje ono zignorowane przez poprzednie wersje sterownika). Jednak istnienie niezakończonych transakcji w dzienniku powoduje ustawienie flagi RECOVER, co oznacza, że taki system plików nie zostanie rozpoznany przez zwykły moduł Ext2. Dzięki temu nie da się rozspójnić dziennika poprzez zamontowanie partycji bez odtworzenia informacji z niego.
Warto też zauważyć, że niczym nie grozi ponowna awaria sprzętu w trakcie aplikowania zmian z dziennika - przy ponownym uruchamianiu bloki zostaną nagrane ponownie. Dziennik jest oznaczany jako pusty dopiero po zakończeniu całego odtwarzania.
Istotną kwestią w unikaniu blokad jest przewidywanie ile bloków może zostać zmodyfikowancych w ramach jednej transakcji. Póki w pliku dziennika jest miejsce, JBD łączy równolegle zachodzące modyfikacje w jedną. Jeśli jednak kończy się miejsce, nowe transakcje zostają wstrzymane. Dlatego przy każdym rozpoczęciu transakcji, Ext3 musi określić ile maksymalnie bloków może zostać zmodyfikowanych.
Najczęstszą praktyką w systemach plików jest journalling jedynie zmian w metadanych (katalogach, i-węzłach, superbloku itp.). Choć gwarantuje to spójność systemu plików, na końcu plików zapisywanych przed awarią mogą pojawić się niepoprawne dane. (Przykład)
Najprostszym sposobem usunięcia tego problemu jest journalling tak metadanych, jak i samych danych pliku. Jest to jednak zbyt kosztowne - każdy zapis dokonywany jest dwukrotnie, najpierw do dziennika a potem do docelowego bloku.
W powyższym przykładzie przed zatwierdzeniem transakcji do journala zostanie dodatkowo wpisany blok z danymi (Blok 2). Podczas odtwarzania dziennika zostanie on zapisany na dysk.
Ext3 domyślnie używa trybu ordered: journallowane są tylko metadane, ale przed ich zatwierdzeniem zostają zapisane wszystkie bloki danych. Działa to nadal nieco wolniej niż journalling samych metadanych, ale znacznie szybciej niż pełny.
(Zachowanie trybu ordered dla powyższego przykładu).Aby zapewnić poprawne działanie trybu ordered, Ext3 stosuje następujące techniki: