All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
To: Felix Blanke <felixblanke@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Problems with incremental send/receive
Date: Fri, 10 Jan 2014 16:02:47 +0800	[thread overview]
Message-ID: <52CFA927.8040107@cn.fujitsu.com> (raw)
In-Reply-To: <CAFTPBc+0G9BR1ugLDXfyDQK9CU+VdC9NRCzKsjYga4TK1PbsPQ@mail.gmail.com>

Hello Felix,

On 01/10/2014 03:26 PM, Felix Blanke wrote:
> Hi Wang,
>
> here are the versioninformation:
>
> server log # btrfs version
> Btrfs v3.12-dirty
> server log # uname -a
> Linux server.home 3.12.6-hardened-r3 #1 SMP Thu Jan 2 13:16:48 CET
> 2014 x86_64 Intel(R) Celeron(R) CPU G1610 @ 2.60GHz GenuineIntel
> GNU/Linux
>
> This should work if I understood you correct?I try your below scripts,

Did you use other subvolume for mounting? If yes, try to remounting
your btrfs filesystem with fs tree(root id=5), and rerun.

Some people reported the same issue for btrfs send/receive recently.
I fixed the problem in send[1], but we can still encounter the same issue in
receive[2]

Hopely, my answer is helpful to you.^_^

[1] https://patchwork.kernel.org/patch/3258971/
[2] https://patchwork.kernel.org/patch/3369111/

Thanks,
Wang
>
> Regards,
> Felix
>
> On Thu, Jan 9, 2014 at 12:36 PM, Felix Blanke <felixblanke@gmail.com> wrote:
>> Hi Wang,
>>
>> thank you for your answer.
>>
>> I am using the latest btrfs-progs with the 3.12 kernel. I don't have
>> access to the machine right now (it looks like it crashed :/) but I
>> can send the exact versions when I'm home.
>>
>> Regards,
>> Felix
>>
>> On Thu, Jan 9, 2014 at 3:10 AM, Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote:
>>> Hi Felix,
>>>
>>> It seems some reported this problem before. The problem for your below case
>>> is because you use latest btrfs-progs(v3.12?), which will need kernel
>>> update,
>>> kernel 3.12 is ok.
>>>
>>> However, i think btrfs-progs should keep compatibility, i will send a patch
>>> to
>>> make things more friendly.
>>>
>>> Thanks,
>>> Wang
>>>
>>> On 01/09/2014 06:04 AM, Felix Blanke wrote:
>>>> Hi List,
>>>>
>>>> My backup stopped working and I can't figure out why. I'm using
>>>> send/receive with the "-p" switch for incremental backups using the
>>>> last snapshot as a parent snapshot for sending only the changed data.
>>>>
>>>> The problem occurs using my own backup script. After I discovered the
>>>> problem I did a quick test using the exact commands from the wiki with
>>>> the same result: It doesn't work. Here is the output:
>>>>
>>>>
>>>> server ~ # ./test_snapshot.sh
>>>> ++ btrfs subvolume snapshot -r /mnt/root1/@root_home/
>>>> /mnt/root1/snapshots/test
>>>> Create a readonly snapshot of '/mnt/root1/@root_home/' in
>>>> '/mnt/root1/snapshots/test'
>>>> ++ sync
>>>> ++ btrfs send /mnt/root1/snapshots/test
>>>> ++ btrfs receive /mnt/backup1/
>>>> At subvol /mnt/root1/snapshots/test
>>>> At subvol test
>>>> ++ btrfs subvolume snapshot -r /mnt/root1/@root_home/
>>>> /mnt/root1/snapshots/test_new
>>>> Create a readonly snapshot of '/mnt/root1/@root_home/' in
>>>> '/mnt/root1/snapshots/test_new'
>>>> ++ sync
>>>> ++ btrfs send -p /mnt/root1/snapshots/test /mnt/root1/snapshots/test_new
>>>> ++ btrfs receive /mnt/backup1/
>>>> At subvol /mnt/root1/snapshots/test_new
>>>> At snapshot test_new
>>>> ERROR: open @/test failed. No such file or directory
>>>>
>>>> I don't get where the "@/" in front of the snapshot name comes from.
>>>> It could be that I had a subvolume named @, but this doesn't exists
>>>> anymore and I don't understand why this would be important for the
>>>> send/receive.
>>>>
>>>> Some more details about the fs:
>>>>
>>>> server ~ # btrfs subvol list /mnt/root1/
>>>> ID 259 gen 568053 top level 5 path @root
>>>> ID 261 gen 568053 top level 5 path @var
>>>> ID 263 gen 568049 top level 5 path @home
>>>> ID 302 gen 568053 top level 5 path @owncloud_chroot
>>>> ID 421 gen 568038 top level 5 path @root_home
>>>> ID 30560 gen 563661 top level 5 path snapshots/home_2014-01-06-19:33_d
>>>> ID 30561 gen 563665 top level 5 path
>>>> snapshots/owncloud_chroot_2014-01-06-19:34_d
>>>> ID 30562 gen 563674 top level 5 path
>>>> snapshots/root_home_2014-01-06-19:38_d
>>>> ID 30563 gen 563675 top level 5 path snapshots/var_2014-01-06-19:39_d
>>>> ID 30564 gen 563697 top level 5 path snapshots/root_2014-01-06-19:50_d
>>>>
>>>> server ~ # btrfs subvol get-default /mnt/root1/
>>>> ID 5 (FS_TREE)
>>>>
>>>> server ~ # ls -l /mnt/root1/
>>>> total 0
>>>> drwxr-xr-x. 1 root root  30 May 10  2013 @home
>>>> drwxr-xr-x. 1 root root 134 Jan  5 19:27 @owncloud_chroot
>>>> drwxr-xr-x. 1 root root 204 Nov 24 18:16 @root
>>>> drwx------. 1 root root 468 Jan  8 22:47 @root_home
>>>> drwxr-xr-x. 1 root root 114 Oct  7 17:39 @var
>>>> drwx------. 1 root root 420 Jan  8 22:50 snapshots
>>>>
>>>>
>>>> Any ideas? Thanks in advance.
>>>>
>>>>
>>>> Regards,
>>>> Felix
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>> the body of a message tomajordomo@vger.kernel.org
>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2014-01-10  8:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 22:04 Problems with incremental send/receive Felix Blanke
2014-01-09  2:10 ` Wang Shilong
2014-01-09 11:36   ` Felix Blanke
2014-01-10  7:26     ` Felix Blanke
2014-01-10  8:02       ` Wang Shilong [this message]
2014-01-10 13:15         ` Felix Blanke
2014-01-10 16:26           ` Duncan

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=52CFA927.8040107@cn.fujitsu.com \
    --to=wangsl.fnst@cn.fujitsu.com \
    --cc=felixblanke@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.