Re: Problems with incremental send/receive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx> 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@xxxxxxxxx>
>> 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@xxxxxxxxxxxxxx>
>>> 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@xxxxxxxxxxxxxxx
>>>>> 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@xxxxxxxxxxxxxxx
>> More majordomo info at  http://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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux