В ответе разработчика Ext4 Теда Тео (Ted Ts'o) раскрыта суть проблемы. Как и другие современные файловые системы, например, XFS, Ext4 реализует задержку записи новых данных, что может занять до 60 секунд. Это повышает производительность и обеспечивает оптимизацию размещения данных на жестком диске.

  KDE и GNOME часто производят чтение и запись небольших объемов информации (например, конфигурационных файлов для персональных настроек). В случае аварии, системе может не хватить времени для передачи данных на файловую систему под ext4, информация в файлах может быть усечена. Это объясняется задержками с распределением данных. Когда новый файл создан, это изменение отмечается в журнале, но данные при этом, все еще не записаны на диск в течении 45 - 150 секунд. После чего, файловая система "догоняет" выделение места для новых файлов и записи данных. Технические подробности (которые, в основном, касаются системных вызовов ftruncate () и rename()), можно найти в ответе разработчика Ext4 на сообщение об ошибке.

  Тэо описывает способы точно определить возможность такого случая и не допускать задержки с распределением, но указывает на то, что другие современные файловые системы, как, например, XFS и новая Btrfs имеют подобные проблемы. Патчи не будут включены в предстоящий релиз ядра 2.6.29, и ставятся в очередь на ядре 2.6.30.

 Тэо говорит, что проблема должна быть исправлена после устранения записи и перезаписи небольших файлов. Он сообщает, что "это больше проблема проектирования, чем всего остального". Программисты привыкли и зависят от поведения Ext3, которое подразумевает синхронизацию каждые 5 секунд и режим журналирования по умолчанию "data=ordered." Для Ext3 режим journalling по умолчанию означает, что метаданные для журнала записываются упорядоченно, поэтому любые связанные данные будут записаны на диск в первую очередь.

Источник