Na stronie śledzącej błędy, dotyczące nadchodzącego wydania Ubuntu 9.04, zgłoszono problem częstej utraty danych podczas korzystania z systemu plików Ext4 – zbliżającego się wielkimi krokami nowego linuksowego standardu.

Raport opisuje utratę plików konfiguracyjnych w sytuacji, gdy KDE 4 zawiesi się tuż po starcie systemu. W ich miejscu pojawiają się zbiory o zerowym rozmiarze i równie niewielkiej przydatności.

Jak się okazuje, przyczyną problemu nie jest błąd programistów, odpowiedzialnych za nowy system plików, lecz raczej nawyki związane ze sposobem działania popularnego obecnie Ext3. Jego młodszy kuzyn zawiera wiele usprawnień, mających na celu zwiększenie wydajności zapisu danych. Jednym z najważniejszych jest wprowadzenie przerwy między wywołaniem operacji zapisania danych, a fizycznym umieszczeniem ich na nośniku. Przerwa ta może trwać od 45 do 150 sekund, podczas których system stara się zoptymalizować sposób umieszczenia plików na dysku, zbierając większe porcje danych do jednorazowej alokacji. Takie zachowanie pomaga zmniejszyć obciążenie procesora oraz oddala zagrożenie fragmentacji plików.

Problem pojawia się, gdy coś spowoduje zawieszenie się systemu w okresie między wywołaniem operacji zapisu, a umieszczeniem danych na nośniku. Z licznika wolnej przestrzeni dyskowej zostanie odjęta odpowiednia wartość, lecz dane mogą nie zostać skopiowane na czas z bufora, gdyż system wciąż czekał z ich alokacją. W ten właśnie sposób powstają pliki o zerowym rozmiarze. Dotyczy to w szczególności niewielkich zbiorów konfiguracyjnych – bardzo często otwieranych i zapisywanych.

Ted Ts’o, programista Ext4, który zajmuje się tym problemem, poinformował, że tak naprawdę podobna sytuacja mogła zdarzyć się również na partycjach Ext3, lecz prawdopodobieństwo jej wystąpienia było znacznie niższe, gdyż Ext3 alokowało pliki po maksymalnie 5 sekundach. Jego zdaniem wina leży po stronie niechlujnych programistów, którzy nie zadbali o to, by w krytycznych momentach dokonać przymusowej alokacji danych.

Twórcy Ext4 postanowili jednak opracować specjalną łatkę, której działanie polegać ma na wykrywaniu sytuacji, gdy plik otwierany jest z flagą O_TRUNC i wymuszaniu alokacji od razu po wywołaniu polecenia zapisu. Wiązać się to jednak będzie z utratą wydajności i nie jest perfekcyjnym rozwiązaniem, lecz tymczasowym sposobem na obejście problemu. Odpowiednia poprawka została już zgłoszona, lecz zostanie włączona dopiero do jądra 2.6.30. Nic chyba jednak nie stoi na przeszkodzie, by twórcy dystrybucji dołączyli ją na własną rękę do aktualnego kernela, co może być ważne, gdyż trzy duże systemy: Ubuntu, Mandriva oraz Fedora, które planowane są na kwiecień, zostaną wydane właśnie z jądrem 2.6.29.

Cała sytuacja spowodowała ostatnio sporo zamieszania. Warto jednak pamiętać, że nie jest ona dramatyczna – gdyż występuje tylko w przypadku zawieszenia się systemu, co nie zdarza się przecież na co dzień. Należy również pamiętać, że alokacja z opóźnieniem jest stosowana w kilku innych popularnych systemach plików. Wykorzystują ją między innymi chwalone powszechnie Reiser4, XFS oraz ZFS – a więc problem dotyczy ich w podobnym stopniu.

Szerszy opis w języku angielskim – szczególnie przydatny dla tych – których ciekawi dokładny opis mechanizmu powstawania obciętych plików, można znaleźć na blogu Ts’o (dzięki uprzejmości rjc).