[PATCH] btrfs-progs: match the max chunk size to the kernel

[Anand Jain <anand.jain@oracle.com>]

For chunk type Single, %metadata_profile and %data_profile in
create_raid_groups() is NULL, so we continue to use the initially
created 8MB chunks for both metadata and data.

8MB is too small. Kernel default chunk size for type Single is 256MB.
Further the mkfs.btrfs created chunk will stay unless relocated or
cleanup during balance. Consider an ENOSPC case due to 8MB metadata
full.

I don't see any reason that mkfs.btrfs should create 8MB chunks for
chunk type Single instead it could match it with the kernel allocation
size of 256MB for the chunk type Single.

For other chunk-types the create_one_raid_group() is called and creates
the required bigger chunks and there is no change with this patch. Also
for fs sizes (-b option) smaller than 256MB there is no issue as the
chunks sizes are 10% of the requested fs-size until the maximum of
256MB.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
The fio in generic/299 is failing to create the files which shall be
deleted in the later part of the test case and the failure happens
only with the MKFS_OPTIONS="-n64K -msingle" only and not with other types
of chunks. This is bit inconsistent. And it appears that in case of
Single chunk type it fails to create (or touch) the necessary file
as the metadata is full, so increasing the metadata chunk size to the
sizes as kernel would create will add consistency.

 volumes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/volumes.c b/volumes.c
index b46bf5988a95..d56f2fc897e3 100644
--- a/volumes.c
+++ b/volumes.c
@@ -1004,7 +1004,7 @@ int btrfs_alloc_chunk(struct btrfs_trans_handle *trans,
 	struct list_head *cur;
 	struct map_lookup *map;
 	int min_stripe_size = SZ_1M;
-	u64 calc_size = SZ_8M;
+	u64 calc_size = SZ_256M;
 	u64 min_free;
 	u64 max_chunk_size = 4 * calc_size;
 	u64 avail = 0;
-- 
1.8.3.1