Problems with incremental send/receive

Problems with incremental send/receive

[Felix Blanke]

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

Re: Problems with incremental send/receive

[Wang Shilong]

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
>

Re: Problems with incremental send/receive

[Felix Blanke]

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
>>
>

Re: Problems with incremental send/receive

[Felix Blanke]

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?

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
>>>
>>

Re: Problems with incremental send/receive

[Wang Shilong]

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
>

Re: Problems with incremental send/receive

[Felix Blanke]

Hi Want,

you were right, I do have a subvolume called "@" on the receive side,
I wasn't aware of that. So I changed the mounting to not use any
subvolume and it did succeed as far as I can see. Thank you for your
help!

Regards,
Felix

On Fri, Jan 10, 2014 at 9:02 AM, Wang Shilong
<wangsl.fnst@cn.fujitsu.com> wrote:
> 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
>>
>

Re: Problems with incremental send/receive

[Duncan]

Felix Blanke posted on Fri, 10 Jan 2014 14:15:07 +0100 as excerpted:

> Hi Want,

[snip]
 
> On Fri, Jan 10, 2014 at 9:02 AM, Wang Shilong

OT, but...

In language circles that's commonly known as a Cupertino, named for the 
fact that some older spellcheckers didn't know the word cooperation, and 
would suggest replacing it with Cupertino (the city), instead of the dash-
compounded co-operation.

So an inappropriate (and often amusing) spellcheck correction is known as 
a Cupertino, with the phenomenon known as the Cupertino effect.

http://en.wiktionary.org/wiki/Cupertino_effect

(I personally would have named it an "allot", the frequent but 
inappropriate suggestion to replace the informal "alot", where the 
suggestion /should/ be the more acceptable "a lot", since that's the case 
where I first became aware of the phenomenon, and I see "allot" used in 
the "alot" context frequently enough that I know I'm definitely not the 
only one to have the problem.)

(See also Mondegreen, Snowclone, and Crashblossom (this one too new to 
appear in wiktionary apparently, but google has it), other christened 
phenomena of common modern language mistakes.)

-- 
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