From: jeffm@suse.com
To: linux-btrfs@vger.kernel.org
Cc: Jeff Mahoney <jeffm@suse.com>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: [PATCH 3/5] btrfs-progs: convert: use search_cache_extent in migrate_one_reserved_range
Date: Thu, 27 Jul 2017 11:47:21 -0400 [thread overview]
Message-ID: <20170727154723.2208-4-jeffm@suse.com> (raw)
In-Reply-To: <20170727154723.2208-1-jeffm@suse.com>
From: Jeff Mahoney <jeffm@suse.com>
When we are looking for extents in migrate_one_reserved_range, it's likely
that there will be multiple extents that fall into the 0-1MB range.
If lookup_cache_extent is called with a range that covers multiple cache
entries, it will return the first entry it encounters while searching
from the top of the tree that happens to fall in that range. That
means that we can end up skipping regions within that range, resulting
in a file system image that can't be rolled back since it wasn't
all migrated properly.
This is reproducible using convert-tests/008-readonly-image. There was
a range from 0-160kB, but the only entry that was returned began at
~ 280kB.
The fix is to use search_cache_extent to iterate through multiple regions
within that range.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
convert/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/convert/main.c b/convert/main.c
index 01657a6..24ed1de 100644
--- a/convert/main.c
+++ b/convert/main.c
@@ -340,10 +340,12 @@ static int migrate_one_reserved_range(struct btrfs_trans_handle *trans,
* migrate ranges that covered by old fs data.
*/
while (cur_off < range_end(range)) {
- cache = lookup_cache_extent(used, cur_off, cur_len);
+ cache = search_cache_extent(used, cur_off);
if (!cache)
break;
cur_off = max(cache->start, cur_off);
+ if (cur_off >= range_end(range))
+ break;
cur_len = min(cache->start + cache->size, range_end(range)) -
cur_off;
BUG_ON(cur_len < root->sectorsize);
--
2.11.0
next prev parent reply other threads:[~2017-07-27 15:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-27 15:47 [PATCH 0/5 v2] btrfs-progs: convert fixes + reiserfs support jeffm
2017-07-27 15:47 ` [PATCH 1/5] btrfs-progs: convert: properly handle reserved ranges while iterating files jeffm
2017-07-28 1:12 ` Qu Wenruo
2017-07-27 15:47 ` [PATCH 2/5] btrfs-progs: convert: add missing newlines for printfs jeffm
2017-07-28 1:24 ` Qu Wenruo
2017-07-27 15:47 ` jeffm [this message]
2017-07-28 1:20 ` [PATCH 3/5] btrfs-progs: convert: use search_cache_extent in migrate_one_reserved_range Qu Wenruo
2017-07-27 15:47 ` [PATCH 4/5] btrfs-progs: tests: fix typo in convert-tests/008-readonly-image jeffm
2017-07-28 1:27 ` Qu Wenruo
2017-07-31 17:01 ` Jeff Mahoney
2017-07-31 7:35 ` Lakshmipathi.G
2017-07-27 15:47 ` [PATCH 5/5] btrfs-progs: convert: add support for converting reiserfs jeffm
2017-08-22 18:14 ` [PATCH 0/5 v2] btrfs-progs: convert fixes + reiserfs support David Sterba
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=20170727154723.2208-4-jeffm@suse.com \
--to=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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).