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

[David Wright <deblis@lionunicorn.co.uk>]

On Mon 02 May 2022 at 01:30:08 (+0200), Vincent Lefevre wrote:
> On 2022-04-30 15:19:21 +0200, Thomas Schmitt wrote:
> > An explanation of the observed problem would need:
> > - a mechanism which delayed the content production of the inode while it
> >   was already in use for open and write,
> > - or a mechanism which caused ext4 to hide the inode to other processes
> >   and to write a wrong birth timestamp,
> > - or a mechanism which deleted the file shortly after it was created and
> >   re-created it 30 seconds later with its full expected content,
> > - or something of which i cannot think yet.
> > 
> > (The birth timestamp happens to match roughly the time when the file finally
> > became visible to other processes. It matches the modification time of the
> > finally visible file.)
> 
> I'm wondering whether the data are transferred from the VFS to ext4
> necessarily within the same openat system call or could just be kept
> in the VFS as long as they are not needed elsewhere, i.e. the VFS
> behaving like a cache. In the latter case, since the VFS doesn't
> have a notion of birth timestamp (from the code I've read), a bug
> in the VFS code could explain the behavior I had observed. This is
> the only explanation I could have.

I'm not very familiar with files' birth as it's a relatively new
addition to filesystems, particularly how to display it even when
present. So I looked it up, and the ext4 wiki says it's the time
at which the inode is created. I also read in ext4 wikipedia:

  Multiblock allocator

    When ext3 appends to a file, it calls the block allocator, once
    for each block. Consequently, if there are multiple concurrent
    writers, files can easily become fragmented on disk. However, ext4
    uses delayed allocation, which allows it to buffer data and
    allocate groups of blocks. Consequently, the multiblock allocator
    can make better choices about allocating files contiguously on
    disk. The multiblock allocator can also be used when files are
    opened in O_DIRECT mode. This feature does not affect the disk
    format.

So I wondered whether a delayed birth time could be caused by the
filesystem waiting a while before it actually starts creating any
allocation for the file on the disk. Having amassed some data,
depending on its size, it decides where it's going to write it,
ie which block group. Only then does it create the file's inode,
so that it can keep file contents and inode close together.

Cheers,
David.