On Tue, Feb 11, 2020 at 11:01:54PM -0500, Zygo Blaxell wrote: > One reboot later: > > # ls -l > total 8448 > -rw-r--r-- 1 root root 92256 Feb 11 20:56 fsync.log > -rw------- 1 root root 8550048 Feb 11 22:09 test-fsync > -rw-r--r-- 1 root root 3652 Feb 11 19:57 transid.log > # cmp test-fsync /boot/vmlinuz > # > > So the file that was fsynced is complete and correct, but the file > that was not fsynced--and 73 minutes of other writes throughout the > filesystem--neatly disappeared. > > This was the third of three consecutive hour-plus transactions on > this host: > > end of transaction timestamp seconds with same transid > 2020-02-11-19-57-39 1581469059 4315.585493582 > 2020-02-11-21-22-06 1581474126 5067.863739094 > [third transaction aborted by reboot 47 minutes later] > > The timestamps don't quite line up here--there is data on the filesystem > after the last superblock update (at 21:22), but still far from current > (73 minutes lost). Maybe btrfs is updating one superblock at a time, > so I only see one of every 3 transid updates with this method? But the > transid increment is always 1, and I'd expect to see increments 3 at a > time if I was missing two thirds of them. Sorry, I have the above backwards: the superblock was updated at 21:22, but the last data that survived without help from fsync was at 20:56, 26 minutes earlier, not later. That makes more sense--the transaction could include only data that was written before the superblock update. transid.log would not contain the last transaction update record, since that record is necessarily written after the transaction is complete. So the file transid.log has the timestamp of the earlier transaction at 19:57. The log update at 19:57:01 is included in the later transaction at 21:22. The log message about the 21:22 transaction died in the reboot, because it was written at 21:22:01 and lost--I only have it because I made copies of the logs to another machine before rebooting.
Attachment:
signature.asc
Description: PGP signature
