On 2022-04-27 11:39:17 +0200, Thomas Schmitt wrote: > If it has indeed to do with the CPU cache then a particular cache would have > delayed its writing to RAM for 30 seconds but would have served its own CPU > with the full results of file system driver and virtual memory activities > around the new file. No inconsistent partial results would have been written > to page cache in RAM which would have caused protests during your attempts > to see the file. > > But i deem it unlikely that the kernel threads which operated filesystem and > virtual memory are (nearly) always running on the same CPU cache which is > not shared with all other CPU cores. > Further, if the memory operations were just pending in some secluded cache > why does the inode then bear the time when that cache would finally have > released its content to the wider accessible RAM.
I was thinking of a potentially specific FS cache. But perhaps this is not related to the CPU at all. It could be that a potential bug (either in the kernel code or in the compiler) would affect some system calls but not others. So, the ">> $out" done in the script would work, but not other kinds of operations on $out. In the strace output of the script, I get openat(AT_FDCWD, "….out", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 when the file is created, then openat(AT_FDCWD, "….out", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 for the commands that append to this file, and one with openat(AT_FDCWD, "….out", O_WRONLY|O_CREAT|O_APPEND, 0666 <unfinished ...> <... openat resumed>) = 3 about 30 seconds later. So, perhaps there were no issues with openat, but when reading the directory, the file could not be found because some internal structures might have been incomplete. This doesn't explain why the birth time of the file was 30 seconds late. But according to fs/ext4/inode.c, inode handling seems a bit complex. To the question why this doesn't occur every time or at least more often: there might have been an interrupt at the wrong place, or something like that. > If i was in your situation, i'd add diagnostic messages to the script in the > hope (or fear) that the glitch happens again. I think that a better thing would be to write a specific test script doing file creations and writes in append mode, that on many files, and see at the end whether some birth times were unexpectedly late. > Especially the inode numbers during and after the script run would be > interesting. But note that getting other information about the file during the script could void the effects of a potential bug. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
