On Tue, Mar 29, 2022 at 10:59:33AM +0100, Filipe Manana wrote:
On Mon, Mar 28, 2022 at 03:41:52PM -0400, Sasha Levin wrote:From: Filipe Manana <fdmanana@xxxxxxxx> [ Upstream commit 23e3337faf73e5bb2610697977e175313d48acb0 ] When an inode has a last_reflink_trans matching the current transaction, we have to take special care when logging its checksums in order to avoid getting checksum items with overlapping ranges in a log tree, which could result in missing checksums after log replay (more on that in the changelogs of commit 40e046acbd2f36 ("Btrfs: fix missing data checksums after replaying a log tree") and commit e289f03ea79bbc ("btrfs: fix corrupt log due to concurrent fsync of inodes with shared extents")). We also need to make sure a full fsync will copy all old file extent items it finds in modified leaves, because they might have been copied from some other inode. However once we fsync an inode, we don't need to keep paying the price of that extra special care in future fsyncs done in the same transaction, unless the inode is used for another reflink operation or the full sync flag is set on it (truncate, failure to allocate extent maps for holes, and other exceptional and infrequent cases). So after we fsync an inode reset its last_unlink_trans to zero. In case another reflink happens, we continue to update the last_reflink_trans of the inode, just as before. Also set last_reflink_trans to the generation of the last transaction that modified the inode whenever we need to set the full sync flag on the inode, just like when we need to load an inode from disk after eviction. Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx> Signed-off-by: David Sterba <dsterba@xxxxxxxx> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>What's the motivation to backport this to stable? It doesn't fix a bug or any regression, as far as I know at least. Or is it to make some other backport easier?
I wasn't sure if it's needed for completeness for the mentioned fixes, so I took it. Can drop it if it's not needed. -- Thanks, Sasha
