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