Przykład operacji prowadzących do błędu przy journallingu tylko metadanych

• Proces chce dopisać na końcu pliku 5 bajtów
• System plików rozpoczyna transakcję
• Znajduje wolny blok
• Zleca zapisanie bitmapy z ustawionym bitem odpowiadającym temu blokowi
• Zleca zapisanie deskryptorów grup ze zaktualizowanymi licznikami
• Zleca zapisanie zmodyfikowanego i-węzła (data modyfikacji, rozmiar, następny blok)
• Zleca zapisanie bloku danych (Blok 2)
• Zatwierdza transakcję
• Urządzenie zapisuje transakcję do dziennika (zmienione bloki oraz polecenie zatwierdzenia)
• Na dysk zostaje zapisana zmodyfikowana mapa bitowa, deskryptory grup i superblok
• Następuje przeładowanie systemu operacyjnego. Nie zostały zapisane bloki z i-węzłem ani z danymi
  System plików jest w tym momencie niespójny (blok oznaczony jako używany nie należy do żadnego i-węzła)
• System zapisuje wszystkie informacje z dziennika (i-węzeł, a także powtórnie bitmapę, deskryptory grup i superblok), po czym oznacza journal jako pusty
  

Zmiany w powyższym przykładzie dla journallingu w trybie ordered

Zanim informacje o modyfikacji i-węzła, bitmapy, deskryptorów grup i superbloku zostaną zatwierdzone w dzienniku, Ext3 zaczeka aż urządzenie zakończy zapis bloku danych:
.
Następnie, po przeładowaniu systemu i odtworzeniu dziennika, system plików będzie zawierał całkowicie poprawne dane:

Przykład ilustrujący problemy przy przydzielaniu zwolnionych bloków

• Proces zleca usunięcie katalogu
• System rozpoczyna transakcję
• System zleca zwolnienie bloku danych katalogu i jego i-węzła (wraz z uaktualnieniem pozostałych struktur)
• Inny proces zleca zapis na końcu pliku
• System przydziela przed chwilą zwolniony blok
• System zleca zapisanie zmodyfikowanych metadanych (jak w poprzednim przykładzie)
• System zleca zapisanie zmienionego bloku
• Blok z danymi zostaje zapisany
  W tym momencie obraz systemu plików w pamięci wygląda tak:
  
• System zostaje zrestartowany, zanim zdąży zapisać blok zatwierdzający transakcję
• Podczas odtwarzania journala, system stwierdza, że ostatnia transakcja nie została zatwierdzona i ignoruje ją.

Taka sytuacja jest szczególnie niepożądana ze względów bezpieczeństwa - użytkownik mógłby wykorzystać ją do stworzenia plików z flagą setuid.

Przykład ilustrujący konieczność użycia Revoke Records w trybie Ordered

• Do dziennika trafia transakcja zapisująca pewne dane do bloku katalogu
• Transakcja zostaje zatwierdzona
• Proces zleca usunięcie katalogu
• System zapisuje transakcję, w której m.in. zwalnia blok katalogu
• Transakcja zostaje zatwierdzona
• Proces zleca zapis na końcu pewnego pliku
• System przydziela właśnie zwolniony blok, zapisuje w nim żądane dane i zatwierdza transakcję
• Wszystkie transakcje zostają zapisane na dysk, ale jeszcze nie usunięte z dziennika
• System zostaje zresetowany
• Podczas odtwarzania dziennika pierwsza transakcja powoduje zamazanie danych pliku danymi katalogu

W tym przykładzie, transakcja usuwająca katalog zawierałaby revoke record, unieważniający transakcję zmieniającą jego dane.