[PATCH 2/3] Btrfs: use btrfs_alloc_data_chunk_ondemand() when allocating space for relocation

[PATCH 2/3] Btrfs: use btrfs_alloc_data_chunk_ondemand() when allocating space for relocation

[fdmanana]

From: Filipe Manana <fdmanana@suse.com>

We currently use btrfs_check_data_free_space() when allocating space for
relocating data extents, but that is not necessary because that function
combines btrfs_alloc_data_chunk_ondemand(), which does the actual space
reservation, and btrfs_qgroup_reserve_data().

We can use btrfs_alloc_data_chunk_ondemand() directly because we know we
do not need to reserve qgroup space since we are dealing with a relocation
tree, which can never have qgroups (btrfs_qgroup_reserve_data() does
nothing as is_fstree() returns false for a relocation tree).

Conversely we can use btrfs_free_reserved_data_space_noquota() directly
instead of btrfs_free_reserved_data_space(), since we had no qgroup
reservation when allocating space.

This change is preparatory work for another patch in this series that
makes relocation reserve the exact amount of space it needs to relocate
a data block group. The function btrfs_check_data_free_space() has
the incovenient of requiring a start offset argument and we will want to
be able to allocate space for multiple ranges, which are not consecutive,
at once.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
 fs/btrfs/relocation.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 3bbae80c752f..11d156995446 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2585,13 +2585,12 @@ int prealloc_file_extent_cluster(struct inode *inode,
 	u64 prealloc_start = cluster->start - offset;
 	u64 prealloc_end = cluster->end - offset;
 	u64 cur_offset;
-	struct extent_changeset *data_reserved = NULL;
 
 	BUG_ON(cluster->start != cluster->boundary[0]);
 	inode_lock(inode);
 
-	ret = btrfs_check_data_free_space(inode, &data_reserved, prealloc_start,
-					  prealloc_end + 1 - prealloc_start);
+	ret = btrfs_alloc_data_chunk_ondemand(BTRFS_I(inode),
+					      prealloc_end + 1 - prealloc_start);
 	if (ret)
 		goto out;
 
@@ -2606,8 +2605,8 @@ int prealloc_file_extent_cluster(struct inode *inode,
 		lock_extent(&BTRFS_I(inode)->io_tree, start, end);
 		num_bytes = end + 1 - start;
 		if (cur_offset < start)
-			btrfs_free_reserved_data_space(inode, data_reserved,
-					cur_offset, start - cur_offset);
+			btrfs_free_reserved_data_space_noquota(inode,
+						       start - cur_offset);
 		ret = btrfs_prealloc_file_range(inode, 0, start,
 						num_bytes, num_bytes,
 						end + 1, &alloc_hint);
@@ -2618,11 +2617,10 @@ int prealloc_file_extent_cluster(struct inode *inode,
 		nr++;
 	}
 	if (cur_offset < prealloc_end)
-		btrfs_free_reserved_data_space(inode, data_reserved,
-				cur_offset, prealloc_end + 1 - cur_offset);
+		btrfs_free_reserved_data_space_noquota(inode,
+					       prealloc_end + 1 - cur_offset);
 out:
 	inode_unlock(inode);
-	extent_changeset_free(data_reserved);
 	return ret;
 }
 
-- 
2.11.0

Re: [PATCH 2/3] Btrfs: use btrfs_alloc_data_chunk_ondemand() when allocating space for relocation

[Nikolay Borisov]

On 9.06.20 г. 13:19 ч., fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> We currently use btrfs_check_data_free_space() when allocating space for
> relocating data extents, but that is not necessary because that function
> combines btrfs_alloc_data_chunk_ondemand(), which does the actual space
> reservation, and btrfs_qgroup_reserve_data().
> 
> We can use btrfs_alloc_data_chunk_ondemand() directly because we know we
> do not need to reserve qgroup space since we are dealing with a relocation
> tree, which can never have qgroups (btrfs_qgroup_reserve_data() does
> nothing as is_fstree() returns false for a relocation tree).
> 
> Conversely we can use btrfs_free_reserved_data_space_noquota() directly
> instead of btrfs_free_reserved_data_space(), since we had no qgroup
> reservation when allocating space.
> 
> This change is preparatory work for another patch in this series that
> makes relocation reserve the exact amount of space it needs to relocate
> a data block group. The function btrfs_check_data_free_space() has
> the incovenient of requiring a start offset argument and we will want to
> be able to allocate space for multiple ranges, which are not consecutive,
> at once.
> 
> Signed-off-by: Filipe Manana <fdmanana@suse.com>

Reviewed-by: Nikolay Borisov <nborisov@suse.com>

Re: [PATCH 2/3] Btrfs: use btrfs_alloc_data_chunk_ondemand() when allocating space for relocation

[David Sterba]

On Tue, Jun 09, 2020 at 11:19:42AM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> We currently use btrfs_check_data_free_space() when allocating space for
> relocating data extents, but that is not necessary because that function
> combines btrfs_alloc_data_chunk_ondemand(), which does the actual space
> reservation, and btrfs_qgroup_reserve_data().
> 
> We can use btrfs_alloc_data_chunk_ondemand() directly because we know we
> do not need to reserve qgroup space since we are dealing with a relocation
> tree, which can never have qgroups (btrfs_qgroup_reserve_data() does
> nothing as is_fstree() returns false for a relocation tree).
> 
> Conversely we can use btrfs_free_reserved_data_space_noquota() directly
> instead of btrfs_free_reserved_data_space(), since we had no qgroup
> reservation when allocating space.
> 
> This change is preparatory work for another patch in this series that
> makes relocation reserve the exact amount of space it needs to relocate
> a data block group.  The function btrfs_check_data_free_space() has
> the incovenient of requiring a start offset argument and we will want to
> be able to allocate space for multiple ranges, which are not consecutive,
> at once.

Patches 1 and 2 are ok, 3/3 is supposed to be dropped so I'll add only
the two. Thanks.