On Thu, Mar 11, 2021 at 6:05 PM Martin Raiber <mar...@urbackup.org> wrote: > > 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?
It could be a bug between aborting a transaction (the error handling/remount ro) and an fsync in progress yes. I'll have to look at that and see if it's possible. Thanks for the report. > > > > >> 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.”
