public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Thumshirn <jth@kernel.org>
To: linux-btrfs@vger.kernel.org
Cc: Josef Bacik <josef@toxicpanda.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	David Sterba <dsterba@suse.com>,
	Naohiro Aota <naohiro.aota@wdc.com>, Qu Wenruo <wqu@suse.com>,
	Filipe Manana <fdmanana@suse.com>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: [PATCH 12/14] btrfs: selftests: add selftest for punching holes into the RAID stripe extents
Date: Thu, 12 Dec 2024 08:55:31 +0100	[thread overview]
Message-ID: <48a5cfb4c94de62c961f36d0a6ff9c9c24902116.1733989299.git.jth@kernel.org> (raw)
In-Reply-To: <cover.1733989299.git.jth@kernel.org>

From: Johannes Thumshirn <johannes.thumshirn@wdc.com>

Add a selftest for punching a hole into a RAID stripe extent. The test
create an 1M extent and punches a 64k bytes long hole at offset of 32k from
the start of the extent.

Afterwards it verifies the start and length of both resulting new extents
"left" and "right" as well as the absence of the hole.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 fs/btrfs/tests/raid-stripe-tree-tests.c | 133 ++++++++++++++++++++++++
 1 file changed, 133 insertions(+)

diff --git a/fs/btrfs/tests/raid-stripe-tree-tests.c b/fs/btrfs/tests/raid-stripe-tree-tests.c
index a815fc5c4dd3..37b87ccb5858 100644
--- a/fs/btrfs/tests/raid-stripe-tree-tests.c
+++ b/fs/btrfs/tests/raid-stripe-tree-tests.c
@@ -31,6 +31,138 @@ static struct btrfs_device *btrfs_device_by_devid(struct btrfs_fs_devices *fs_de
 	return NULL;
 }
 
+/* Test punching a hole into a single RAID stripe-extent. */
+static int test_punch_hole(struct btrfs_trans_handle *trans)
+{
+	struct btrfs_fs_info *fs_info = trans->fs_info;
+	struct btrfs_io_context *bioc;
+	struct btrfs_io_stripe io_stripe = { 0 };
+	u64 map_type = RST_TEST_RAID1_TYPE;
+	u64 logical1 = SZ_1M;
+	u64 hole_start = logical1 + SZ_32K;
+	u64 hole_len = SZ_64K;
+	u64 logical2 = hole_start + hole_len;
+	u64 len = SZ_1M;
+	u64 len1 = SZ_32K;
+	u64 len2 = len - len1 - hole_len;
+	int ret;
+
+	bioc = alloc_btrfs_io_context(fs_info, logical1, RST_TEST_NUM_DEVICES);
+	if (!bioc) {
+		test_std_err(TEST_ALLOC_IO_CONTEXT);
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	io_stripe.dev = btrfs_device_by_devid(fs_info->fs_devices, 0);
+	bioc->map_type = map_type;
+	bioc->size = len;
+
+	for (int i = 0; i < RST_TEST_NUM_DEVICES; i++) {
+		struct btrfs_io_stripe *stripe = &bioc->stripes[i];
+
+		stripe->dev = btrfs_device_by_devid(fs_info->fs_devices, i);
+		if (!stripe->dev) {
+			test_err("cannot find device with devid %d", i);
+			ret = -EINVAL;
+			goto out;
+		}
+
+		stripe->physical = logical1 + i * SZ_1G;
+	}
+
+	ret = btrfs_insert_one_raid_extent(trans, bioc);
+	if (ret) {
+		test_err("inserting RAID extent failed: %d", ret);
+		goto out;
+	}
+
+	ret = btrfs_get_raid_extent_offset(fs_info, logical1, &len, map_type, 0,
+					   &io_stripe);
+	if (ret) {
+		test_err("lookup of RAID extent [%llu, %llu] failed", logical1,
+			 logical1 + len);
+		goto out;
+	}
+
+	if (io_stripe.physical != logical1) {
+		test_err("invalid physical address, expected %llu got %llu",
+			 logical1, io_stripe.physical);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (len != SZ_1M) {
+		test_err("invalid stripe length, expected %llu got %llu",
+			 (u64)SZ_1M, len);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = btrfs_delete_raid_extent(trans, hole_start, hole_len);
+	if (ret) {
+		test_err("deleting RAID extent [%llu, %llu] failed",
+			 hole_start, hole_start + hole_len);
+		goto out;
+	}
+
+	ret = btrfs_get_raid_extent_offset(fs_info, logical1, &len1, map_type,
+					   0, &io_stripe);
+	if (ret) {
+		test_err("lookup of RAID extent [%llu, %llu] failed",
+			 logical1, logical1 + len1);
+		goto out;
+	}
+
+	if (io_stripe.physical != logical1) {
+		test_err("invalid physical address, expected %llu, got %llu",
+			 logical1, io_stripe.physical);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (len1 != SZ_32K) {
+		test_err("invalid stripe length, expected %llu, got %llu",
+			 (u64)SZ_32K, len1);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = btrfs_get_raid_extent_offset(fs_info, logical2, &len2, map_type,
+					   0, &io_stripe);
+	if (ret) {
+		test_err("lookup of RAID extent [%llu, %llu] failed", logical2,
+			 logical2 + len2);
+		goto out;
+	}
+
+	if (io_stripe.physical != logical2) {
+		test_err("invalid physical address, expected %llu, got %llu",
+			 logical2, io_stripe.physical);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	/* Check for the absence of the hole. */
+	ret = btrfs_get_raid_extent_offset(fs_info, hole_start, &hole_len,
+					   map_type, 0, &io_stripe);
+	if (ret != -ENODATA) {
+		ret = -EINVAL;
+		test_err("lookup of RAID extent [%llu, %llu] succeeded, should fail",
+			 hole_start, hole_start + SZ_64K);
+		goto out;
+	}
+
+	ret = btrfs_delete_raid_extent(trans, logical1, len1);
+	if (ret)
+		goto out;
+
+	ret = btrfs_delete_raid_extent(trans, logical2, len2);
+out:
+	btrfs_put_bioc(bioc);
+	return ret;
+}
+
 /*
  * Test a 1M RST write that spans two adjecent RST items on disk and then
  * delete a portion starting in the first item and spanning into the second
@@ -612,6 +744,7 @@ static const test_func_t tests[] = {
 	test_tail_delete,
 	test_front_delete,
 	test_front_delete_prev_item,
+	test_punch_hole,
 };
 
 static int run_test(test_func_t test, u32 sectorsize, u32 nodesize)
-- 
2.43.0


  parent reply	other threads:[~2024-12-12  7:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12  7:55 [PATCH 00/14] btrfs: more RST delete fixes Johannes Thumshirn
2024-12-12  7:55 ` [PATCH 01/14] btrfs: don't try to delete RAID stripe-extents if we don't need to Johannes Thumshirn
2024-12-17 14:40   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 02/14] btrfs: assert RAID stripe-extent length is always greater than 0 Johannes Thumshirn
2024-12-17 14:46   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 03/14] btrfs: fix search when deleting a RAID stripe-extent Johannes Thumshirn
2024-12-17 14:56   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 04/14] btrfs: fix front delete range calculation for RAID stripe extents Johannes Thumshirn
2024-12-17 15:02   ` Filipe Manana
2024-12-18  9:55     ` Johannes Thumshirn
2024-12-12  7:55 ` [PATCH 05/14] btrfs: fix tail delete of RAID stripe-extents Johannes Thumshirn
2024-12-17 15:45   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 06/14] btrfs: fix deletion of a range spanning parts two RAID stripe extents Johannes Thumshirn
2024-12-17 15:58   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 07/14] btrfs: implement hole punching for " Johannes Thumshirn
2024-12-17 16:05   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 08/14] btrfs: don't use btrfs_set_item_key_safe on RAID stripe-extents Johannes Thumshirn
2024-12-17 16:23   ` Filipe Manana
2024-12-18 10:00     ` Johannes Thumshirn
2024-12-19 10:03     ` Johannes Thumshirn
2024-12-12  7:55 ` [PATCH 09/14] btrfs: selftests: check for correct return value of failed lookup Johannes Thumshirn
2024-12-17 16:24   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 10/14] btrfs: selftests: don't split RAID extents in half Johannes Thumshirn
2024-12-17 16:31   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 11/14] btrfs: selftests: test RAID stripe-tree deletion spanning two items Johannes Thumshirn
2024-12-17 16:43   ` Filipe Manana
2024-12-12  7:55 ` Johannes Thumshirn [this message]
2024-12-17 16:50   ` [PATCH 12/14] btrfs: selftests: add selftest for punching holes into the RAID stripe extents Filipe Manana
2024-12-12  7:55 ` [PATCH 13/14] btrfs: selftests: add test for punching a hole into 3 RAID stripe-extents Johannes Thumshirn
2024-12-17 16:55   ` Filipe Manana
2024-12-12  7:55 ` [PATCH 14/14] btrfs: selftests: add a selftest for deleting two out of three extents Johannes Thumshirn
2024-12-17 16:59   ` Filipe Manana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48a5cfb4c94de62c961f36d0a6ff9c9c24902116.1733989299.git.jth@kernel.org \
    --to=jth@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=dsterba@suse.com \
    --cc=fdmanana@suse.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox