From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Copying a disk containing a btrfs filesystem
Date: Fri, 11 Apr 2014 00:35:38 +0000 (UTC) [thread overview]
Message-ID: <pan$4fcd0$87fc5afe$80e50794$911d5718@cox.net> (raw)
In-Reply-To: 1924982.LHpDrRg8EQ@fuchsia
Michael Schuerig posted on Thu, 10 Apr 2014 18:24:00 +0200 as excerpted:
> I *think* send/receive with clone sources might be the key to a
> solution. I'm still hoping that someone with a far better understanding
> of btrfs than me gives it a try first...
Well, there's both that (which I don't know enough about to discuss in
any intelligent way at all), and the fact that at least until very (very)
recently (like recent enough I'm not sure it'll all be in 2.15 yet),
btrfs send/receive still had some serious corner-case bugs, such that to
my knowledge if it worked without error it was reliable, there were
numbers of cases (like where it was originally subdir /a/b/, and then
switched to /b/a, reversing the nesting) where it would spit out errors,
leaving the receive in a half-received state.
So it worked for some people but not others, and for some it would work
for awhile, then would start erroring out, whenever they hit whatever
corner-case.
Regulars on this list will have seen all the recent work going into send/
receive bug tracing and fixing, however, which will of course ultimately
make it far more reliable than it had been. Surely it's already far more
reliable, as a fair number of those corner cases have now been found and
dealt with.
But what I do NOT know yet, is where in the process we are, in terms of
/reliable/ send/receive. Relatively, we're certainly closer than we
were, but did that move use from say 80% to 90% reliable, or from 80% to
97 or 98% reliable (which is about where I'd put general btrfs at this
point), or from 90% to 98-ish% reliable, or... ?
Without that knowledge, even if you did know the specific CL options you
needed, I'd still consider it very much a "great if it works, but don't
count on it until you actually see it complete without errors, and even
then, be aware that the next time you try it could error out, because
it's still very much in bug-fixing-phase" solution.
Meanwhile, the ddrescue solution is mature technology, proven to work
with many different types of filesystems over many years, now, so that's
the basket I'd be putting my resource eggs into at this point. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-04-11 0:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 13:21 Copying a disk containing a btrfs filesystem Michael Schuerig
2014-04-10 13:58 ` Duncan
2014-04-10 14:53 ` Michael Schuerig
2014-04-10 14:00 ` George Eleftheriou
2014-04-10 15:15 ` Duncan
2014-04-10 15:51 ` Michael Schuerig
2014-04-10 16:01 ` George Eleftheriou
2014-04-10 16:24 ` Michael Schuerig
2014-04-11 0:35 ` Duncan [this message]
2014-04-10 18:15 ` Martin Steigerwald
2014-04-10 17:17 ` Jan Kouba
2014-04-10 18:36 ` Michael Schuerig
2014-04-10 22:25 ` Jan Kouba
2014-04-11 10:39 ` Brendan Hide
2014-04-16 11:12 ` Michael Schuerig
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='pan$4fcd0$87fc5afe$80e50794$911d5718@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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).