From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: junlion@tormail.org
Cc: Alex Lyakas <alex.btrfs@zadarastorage.com>, linux-btrfs@vger.kernel.org
Subject: Re: Incremental btrfs receive in opposite direction fails
Date: Wed, 02 Jan 2013 17:57:32 +0100 [thread overview]
Message-ID: <50E466FC.1070802@jan-o-sch.net> (raw)
In-Reply-To: <1TpCWu-000Fz2-6t@internal.tormail.org>
Hi,
I admit I haven't completely understood what you're trying to achieve. You can
only receive an incremental stream if the internal (!) file system state on the
receiver's side is the same as on the sender's. Thus I don't see where setting a
uuid to trick btrfs receive could do you any good.
On Sun, December 30, 2012 at 07:40 (+0100), junlion wrote:
> On 2012-12-29 15:00 +0200, Alex Lyakas wrote:
>> There is no special repo, but you may want, in addition to the patch
>> you mentioned, apply this one as well:
>> https://patchwork.kernel.org/patch/1604391/
>
> Very useful! Somehow a few lines got wrapped though.
>
>>> Is there a way for me to directly change the received_uuid of
>>> /mnt/bak/.snap to make it identical to the UUID of /.snap? This looks
>>> like the easiest way if I only need to do it once.
>> There is no implemented way, but since you debugged this far, you can
>> put up some code that sends BTRFS_IOC_SET_RECEIVED_SUBVOL, which is
>> the one setting the received_uuid (and some other small stuff, please
>> check the kernel code for it).
>
> Ah, BTRFS_IOC_SET_RECEIVED_SUBVOL. Thanks for pointing me in the right
> direction. After some hacking, it worked without eating my data... These
> are the two commands to run before the failing one:
>
> btrfs subvolume snapshot /mnt/bak/.snap /mnt/bak/.snap-mangled
> uu / .snap /mnt/bak/.snap-mangled
>
> ... where uu is my crude little received_uuid and stransid display and
> adjustment tool. I've attached its source.
Still in doubt, I'd like to recommend checking with Arne's fssum tool if both
file systems are really the same now. You can fetch and build from his repository at
git://git.kernel.org/pub/scm/linux/kernel/git/arne/far-progs.git
As a general rule, please send patches inline for people to quote them when
commenting.
> Would be cool if someone modified btrfs send/receive to handle this use
> case automatically, but it's too difficult for me.
We could completely drop the check leading to the "could not find parent
subvolume" error message, if someone explained why removing it was sensible.
Looking forward to your explanation!
-Jan
next prev parent reply other threads:[~2013-01-02 16:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 22:42 Incremental btrfs receive in opposite direction fails junlion
2012-12-29 13:00 ` Alex Lyakas
2012-12-30 6:40 ` junlion
2013-01-02 16:57 ` Jan Schmidt [this message]
2013-01-02 20:56 ` Jun Lion
[not found] ` <20130102205351.GA2242@localhost>
2013-01-02 22:19 ` junlion
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=50E466FC.1070802@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=alex.btrfs@zadarastorage.com \
--cc=junlion@tormail.org \
--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).