From 5de63ab1c9fcd49794cf52db91efa1df00c683b8 Mon Sep 17 00:00:00 2001
From: Qu Wenruo <wqu@suse.com>
Date: Tue, 16 Jun 2020 14:32:30 +0800
Subject: [PATCH] btrfs-progs: mkfs-tests: Add test case to verify the
 --rootdir size limit

Add a test case to ensure we can create a 350M fs with 128M rootdir.

Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
---
 tests/mkfs-tests/021-rootdir-size/test.sh | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100755 tests/mkfs-tests/021-rootdir-size/test.sh

diff --git a/tests/mkfs-tests/021-rootdir-size/test.sh b/tests/mkfs-tests/021-rootdir-size/test.sh
new file mode 100755
index 00000000..064476fd
--- /dev/null
+++ b/tests/mkfs-tests/021-rootdir-size/test.sh
@@ -0,0 +1,22 @@
+#!/bin/bash
+# Regression test for mkfs.btrfs --rootdir with DUP data profile and rootdir
+# size near the limit of the device.
+#
+# There is a bug that makes mkfs.btrfs always to create unnecessary SINGLE
+# chunks, which eats up a lot of space and leads to unexpected ENOSPC bugs.
+
+source "$TEST_TOP/common"
+
+check_prereq mkfs.btrfs
+prepare_test_dev
+
+tmp=$(mktemp -d --tmpdir btrfs-progs-mkfs.rootdirXXXXXXX)
+
+fallocate -l 128M $tmp/large_file
+
+# We should be able to create the fs with size limit to 2 * (128 + 32 + 8)
+# which is 336M. Here we round it up to 350M.
+run_check "$TOP/mkfs.btrfs" -f --rootdir "$tmp" -d dup -b 350M "$TEST_DEV"
+run_check "$TOP/btrfs" check "$TEST_DEV"
+
+rm -rf -- "$tmp"