Delayed allocation and potential data loss
The delayed allocation poses some additional risk of data loss in cases where the system crashes before all data has been written to the disk.
The typical scenario is a program that replaces the content of a file, without forcing a write to the disk with fsync. If the system crashes shortly afterwards, it is really undefined what is supposed to happen. However, users have come to expect that the disk holds either the old version or the new version of the file, a behaviour that ext3 would usually yield. Whereas the ext4 code in kernel 2.6.28 will often have truncated the file to zero length before the crash, but not yet written the new version, so that the contents of the file is lost.
Many people find such system behavior unacceptable. A significant issue is that fixing the bug, by using fsync more often, could lead to severe performance penalties on ext3 file-systems mounted with the data=ordered flag (the default on most Linux distributions). Given that both file-systems will be in use for some time, this complicates matters enormously for end-user application developers. In response, Theodore Ts’o has written some patches for ext4 that cause it to limit its delayed allocation in these common cases. For a small cost in performance, this will significantly increase the chance that a version of the file survives the crash.
The new patches are expected to become part of the mainline kernel 2.6.30. Various distributions may choose to backport them to 2.6.28 or 2.6.29, for instance Ubuntu made them part of the 2.6.28 kernel in version 9.04 — Jaunty Jackalope.