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.