Re: file born 30 seconds after its creation on ext4 - bug?

[Curt <curty@free.fr>]

On 2022-04-30, Thomas Schmitt <scdbackup@gmx.net> wrote:
>
> Indeed. With normal filesystem operations there should be no need to call
> something like sync(2) in order to get a consistent representation of the
> current filesystem state.
>

What does the following mean, then, in that light:

 Because of delayed allocation and other performance optimizations, ext4's
 behavior of writing files to disk is different from ext3. In ext4, when a
 program writes to the file system, it is not guaranteed to be on-disk unless
 the program issues an fsync() call afterwards. 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-ext4

Or this:

 So on ext4 ‘data=ordered’ and ‘data=writeback’ are somehow similar when a file
 is enlarged, which is quite confusing and not clearly stated in the man pages.
 And the delayed allocation will actually commit the data to disk only after
 30-150 seconds (it is not very clear on this exact window of data loss) even
 when ‘commit=5′ is supposed (cf. ‘man mount’) to do it after 5 seconds.  In
 conclusion, ext4 with default options guarantees after a crash only the
 atomicity and consistency of the filesystem changes (all metadata) with a
 maximum loss of 5 seconds on metadata changes. The data changes may suffer a
 loss of 30-150 seconds and in the majority of cases all changed files in this
 window will be completely wiped with zero bytes! The atomicity of file changes
 is not working anymore with the rename-idiom.

https://www.pointsoftware.ch/2014/02/05/linux-filesystems-part-4-ext4-vs-ext3-and-why-delayed-allocation-is-bad/

Or maybe none of this is  pertinent.