Messages in this thread | | | Date | Thu, 31 Mar 2022 12:59:33 -0400 | From | Sasha Levin <> | Subject | Re: [PATCH AUTOSEL 5.17 17/21] btrfs: reset last_reflink_trans after fsyncing inode |
| |
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@suse.com> >> >> [ 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@suse.com> >> Signed-off-by: David Sterba <dsterba@suse.com> >> Signed-off-by: Sasha Levin <sashal@kernel.org> > >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
| |