On 11.03.2021 15:43 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 think I rebooted via "echo b > /proc/sysrq-trigger". But at that point it probably didn't write to disk_config.dat anymore (for more than the commit interval). I'm also not sure about the delay of me noticing those multiple files (since it doesn't cause any problems) -- can't reproduce. This is the same machine and file system with ENOSPC in btrfs_async_reclaim_metadata_space -> flush_space -> btrfs_run_delayed_refs. Could be that something went wrong with the error handling/remount-ro w.r.t. to the tree log? > >> So far no negative consequences... (except that programs might get confused). >> >> echo 3 > /proc/sys/vm/drop_caches doesn't help. >> >> Regards, >> Martin Raiber
