Message ID | 32f9e43d999fcfaa2927513d7563790a5292fd7b.1616764397.git.fdmanana@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | btrfs: update outdated comment at btrfs_replace_file_extents() | expand |
On Fri, Mar 26, 2021 at 01:14:41PM +0000, fdmanana@kernel.org wrote: > From: Filipe Manana <fdmanana@suse.com> > > There is a comment at btrfs_replace_file_extents() that mentions that we > set the full sync flag on an inode when cloning into a file with a size > greater than or equals to 16MiB, through try_release_extent_mapping() when > we truncate the page cache after replacing file extents during a clone > operation. > > That is not true anymore since commit 5e548b32018d96 ("btrfs: do not set > the full sync flag on the inode during page release"), so update the > comment to remove that part and rephrase it slightly to make it more > clear why the full sync flag is set at btrfs_replace_file_extents(). > > Signed-off-by: Filipe Manana <fdmanana@suse.com> Added to misc-next, thanks.
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index c666d20370c1..42634658815f 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2765,10 +2765,8 @@ int btrfs_replace_file_extents(struct btrfs_inode *inode, /* * If we were cloning, force the next fsync to be a full one since we * we replaced (or just dropped in the case of cloning holes when - * NO_HOLES is enabled) extents and extent maps. - * This is for the sake of simplicity, and cloning into files larger - * than 16Mb would force the full fsync any way (when - * try_release_extent_mapping() is invoked during page cache truncation. + * NO_HOLES is enabled) file extent items and did not setup new extent + * maps for the replacement extents (or holes). */ if (extent_info && !extent_info->is_new_extent) set_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &inode->runtime_flags);