linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gu Jinxiang <gujx@cn.fujitsu.com>
To: <linux-btrfs@vger.kernel.org>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>
Subject: [PATCH v5 02/15] btrfs-progs: Allow __btrfs_map_block_v2 to remove unrelated stripes
Date: Sat, 15 Jul 2017 17:10:40 +0800	[thread overview]
Message-ID: <20170715091053.19725-2-gujx@cn.fujitsu.com> (raw)
In-Reply-To: <20170715091053.19725-1-gujx@cn.fujitsu.com>

From: Qu Wenruo <quwenruo@cn.fujitsu.com>

For READ, caller normally hopes to get what they request, other than
full stripe map.

In this case, we should remove unrelated stripe map, just like the
following case:
               32K               96K
               |<-request range->|
         0              64k           128K
RAID0:   |    Data 1    |   Data 2    |
              disk1         disk2
Before this patch, we return the full stripe:
Stripe 0: Logical 0, Physical X, Len 64K, Dev disk1
Stripe 1: Logical 64k, Physical Y, Len 64K, Dev disk2

After this patch, we limit the stripe result to the request range:
Stripe 0: Logical 32K, Physical X+32K, Len 32K, Dev disk1
Stripe 1: Logical 64k, Physical Y, Len 32K, Dev disk2

And if it's a RAID5/6 stripe, we just handle it like RAID0, ignoring
parities.

This should make caller easier to use.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Gu Jinxiang <gujx@cn.fujitsu.com>
---
 volumes.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/volumes.c b/volumes.c
index 3116f8c..66fe365 100644
--- a/volumes.c
+++ b/volumes.c
@@ -1741,6 +1741,107 @@ static int fill_full_map_block(struct map_lookup *map, u64 start, u64 length,
 	return 0;
 }
 
+static void del_one_stripe(struct btrfs_map_block *map_block, int i)
+{
+	int cur_nr = map_block->num_stripes;
+	int size_left = (cur_nr - 1 - i) * sizeof(struct btrfs_map_stripe);
+
+	memmove(&map_block->stripes[i], &map_block->stripes[i + 1], size_left);
+	map_block->num_stripes--;
+}
+
+static void remove_unrelated_stripes(struct map_lookup *map,
+				     int rw, u64 start, u64 length,
+				     struct btrfs_map_block *map_block)
+{
+	int i = 0;
+	/*
+	 * RAID5/6 write must use full stripe.
+	 * No need to do anything.
+	 */
+	if (map->type & (BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6) &&
+	    rw == WRITE)
+		return;
+
+	/*
+	 * For RAID0/1/10/DUP, whatever read/write, we can remove unrelated
+	 * stripes without causing anything wrong.
+	 * RAID5/6 READ is just like RAID0, we don't care parity unless we need
+	 * to recovery.
+	 * For recovery, rw should be set to WRITE.
+	 */
+	while (i < map_block->num_stripes) {
+		struct btrfs_map_stripe *stripe;
+		u64 orig_logical; /* Original stripe logical start */
+		u64 orig_end; /* Original stripe logical end */
+
+		stripe = &map_block->stripes[i];
+
+		/*
+		 * For READ, we don't really care parity
+		 */
+		if (stripe->logical == BTRFS_RAID5_P_STRIPE ||
+		    stripe->logical == BTRFS_RAID6_Q_STRIPE) {
+			del_one_stripe(map_block, i);
+			continue;
+		}
+		/* Completely unrelated stripe */
+		if (stripe->logical >= start + length ||
+		    stripe->logical + stripe->length <= start) {
+			del_one_stripe(map_block, i);
+			continue;
+		}
+		/* Covered stripe, modify its logical and physical */
+		orig_logical = stripe->logical;
+		orig_end = stripe->logical + stripe->length;
+		if (start + length <= orig_end) {
+			/*
+			 * |<--range-->|
+			 *   |  stripe   |
+			 * Or
+			 *     |<range>|
+			 *   |  stripe   |
+			 */
+			stripe->logical = max(orig_logical, start);
+			stripe->length = start + length;
+			stripe->physical += stripe->logical - orig_logical;
+		} else if (start >= orig_logical) {
+			/*
+			 *     |<-range--->|
+			 * |  stripe     |
+			 * Or
+			 *     |<range>|
+			 * |  stripe     |
+			 */
+			stripe->logical = start;
+			stripe->length = min(orig_end, start + length);
+			stripe->physical += stripe->logical - orig_logical;
+		}
+		/*
+		 * Remaining case:
+		 * |<----range----->|
+		 *   | stripe |
+		 * No need to do any modification
+		 */
+		i++;
+	}
+
+	/* Recaculate map_block size */
+	map_block->start = 0;
+	map_block->length = 0;
+	for (i = 0; i < map_block->num_stripes; i++) {
+		struct btrfs_map_stripe *stripe;
+
+		stripe = &map_block->stripes[i];
+		if (stripe->logical > map_block->start)
+			map_block->start = stripe->logical;
+		if (stripe->logical + stripe->length >
+		    map_block->start + map_block->length)
+			map_block->length = stripe->logical + stripe->length -
+					    map_block->start;
+	}
+}
+
 int __btrfs_map_block_v2(struct btrfs_fs_info *fs_info, int rw, u64 logical,
 			 u64 length, struct btrfs_map_block **map_ret)
 {
@@ -1776,7 +1877,7 @@ int __btrfs_map_block_v2(struct btrfs_fs_info *fs_info, int rw, u64 logical,
 		free(map_block);
 		return ret;
 	}
-	/* TODO: Remove unrelated map_stripes for READ operation */
+	remove_unrelated_stripes(map, rw, logical, length, map_block);
 
 	*map_ret = map_block;
 	return 0;
-- 
2.9.4




  reply	other threads:[~2017-07-15  9:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-15  9:10 [PATCH v5 01/15] btrfs-progs: Introduce new btrfs_map_block function which returns more unified result Gu Jinxiang
2017-07-15  9:10 ` Gu Jinxiang [this message]
2017-07-15  9:10 ` [PATCH v5 03/15] btrfs-progs: csum: Introduce function to read out data csums Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 04/15] btrfs-progs: scrub: Introduce structures to support offline scrub for RAID56 Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 05/15] btrfs-progs: scrub: Introduce functions to scrub mirror based tree block Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 06/15] btrfs-progs: scrub: Introduce functions to scrub mirror based data blocks Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 07/15] btrfs-progs: scrub: Introduce function to scrub one mirror-based extent Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 08/15] btrfs-progs: scrub: Introduce function to scrub one data stripe Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 09/15] btrfs-progs: scrub: Introduce function to verify parities Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 10/15] btrfs-progs: extent-tree: Introduce function to check if there is any extent in given range Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 11/15] btrfs-progs: scrub: Introduce function to recover data parity Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 12/15] btrfs-progs: scrub: Introduce helper to write a full stripe Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 13/15] btrfs-progs: scrub: Introduce a function to scrub one " Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 14/15] btrfs-progs: scrub: Introduce function to check a whole block group Gu Jinxiang
2017-07-15  9:10 ` [PATCH v5 15/15] btrfs-progs: scrub: Introduce offline scrub function Gu Jinxiang
2017-07-15  9:20 ` [PATCH v5 01/15] btrfs-progs: Introduce new btrfs_map_block function which returns more unified result Qu Wenruo
2017-07-18  6:33 ` [PATCH 00/15] Btrfs-progs offline scrub Gu Jinxiang
2017-07-19 16:45   ` Marco Lorenzo Crociani
2017-07-20  3:39     ` Qu Wenruo
2017-07-20  8:55       ` Marco Lorenzo Crociani
2017-07-20  9:10         ` Qu Wenruo
2017-07-20  9:17           ` Qu Wenruo
2017-07-20  9:40             ` Marco Lorenzo Crociani
2017-07-20  9:51               ` Qu Wenruo
2017-08-22  9:45   ` Gu, Jinxiang

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=20170715091053.19725-2-gujx@cn.fujitsu.com \
    --to=gujx@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.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;
as well as URLs for NNTP newsgroup(s).