On Thu, Mar 11, 2021 at 02:43:26PM +0000, Filipe Manana wrote: > On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber <mar...@urbackup.org> wrote: > > > > Hi, > > > > I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg, > > no scrub errors: > > > > ls -lh > > total 19G > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat > > ... > > > > disk_config.dat gets written to using fsync rename ( write new version to > > disk_config.dat.new, fsync disk_config.dat.new, then rename to > > disk_config.dat -- it is missing the parent directory fsync). > > That's interesting. > > I've just tried something like the following on 5.10.15 (and 5.12-rc2): > > create disk_config.dat > sync > for ((i = 0; i < 10; i++)); do > create disk_config.dat.new > write to disk_config.dat.new > fsync disk_config.dat.new > mv -f disk_config.dat.new disk_config.dat > done > <power fail> > mount fs > list directory > > I only get one file with the name disk_config.dat and one file with > the name disk_config.dat.new. > File disk_config.dat has the data written at iteration 9 and > disk_config.dat.new has the data written at iteration 10 (expected). > > You haven't mentioned, but I suppose you had a power failure / unclean > shutdown somewhere after an fsync, right? > Is this something you can reproduce at will?
I've seen this off and on as far back as kernel 4.4. Usually (only?) happens on machines with metadata-heavy write loads at the time of the fsync. Very easy to reproduce if you hit a transaction deadlock bug (which happened to be a lot more common a few years ago), these inodeless filenames would show up almost every time if fsync was called before rename. Somewhere between 4.9 and 4.14, it became possible to create new files with the same names as the inodeless filenames, and the bug became much less annoying (the filenames would even go away by themselves sometimes). Then the bug became harder to spot--earler versions of the bug would stop an application dead with a filename that could never be used again. Later versions didn't break anything, so they could only be found by looking for errors when running e.g. 'find' or 'rsync'. The issue never got near the top of my bug list, and until today I thought it had been quietly fixed before 5.1. I guess it's still active, or a new bug has replaced it. The last instance I recorded of this issue was found on a filesystem in late 2019, although I don't know which kernel was running at the time the inodeless filename was created (could have been anything between 4.4 and 5.0, though probably not before 4.14 because I would have been forced to burn the subvol if it happened on an earlier kernel). > > So far no negative consequences... (except that programs might get > > confused). > > > > echo 3 > /proc/sys/vm/drop_caches doesn't help. > > > > Regards, > > Martin Raiber > > > > > -- > Filipe David Manana, > > “Whether you think you can, or you think you can't — you're right.”
