I am having problems with btrfs send using the current version of btrfs-progs. When trying to send a snapshot I get the error "ERROR: open @/test-snap failed. No such file or directory". I traced the bug down to have been introduced by commit 5f9c5a23. Older versions of btrfs-progs do not show this problem. I am running the current version of btrfs-progs from git and a current kernel: # uname -a Linux r2d2 3.13.0gabriel-1+ #2 SMP Thu Jan 23 20:53:57 CET 2014 x86_64 x86_64 x86_64 GNU/Linux # sudo btrfs fi show / Label: btrfs_pool uuid: e8c27a85-84b2-465c-8b0f-914452d0f9cc Total devices 1 FS bytes used 12.84GiB devid 1 size 89.61GiB used 17.57GiB path /dev/disk/by-uuid/e8c27a85-84b2-465c-8b0f-914452d0f9cc Btrfs v3.12 # sudo btrfs sub create /testvol Create subvolume '//testvol' # sudo btrfs sub list / ID 256 gen 22381 top level 5 path @ ID 260 gen 18872 top level 256 path .snapshots/backup_2013-09-21 ID 265 gen 20136 top level 256 path .snapshots/backup_2013-10-27 ID 266 gen 20246 top level 256 path .snapshots/backup_2013-11-02 ID 267 gen 21962 top level 256 path var/lib/lxc ID 270 gen 21966 top level 256 path var/lib/lxc/ubuntu-test/rootfs ID 271 gen 21960 top level 256 path var/lib/lxc/ubuntu-test/rootfs.fresh-install ID 272 gen 22066 top level 256 path .snapshots/backup_2014-01-24 ID 279 gen 22381 top level 256 path testvol # sudo btrfs sub snap -r /testvol /test-snap Create a readonly snapshot of '/testvol' in '//test-snap' # sudo btrfs sub list / ID 256 gen 22384 top level 5 path @ ID 260 gen 18872 top level 256 path .snapshots/backup_2013-09-21 ID 265 gen 20136 top level 256 path .snapshots/backup_2013-10-27 ID 266 gen 20246 top level 256 path .snapshots/backup_2013-11-02 ID 267 gen 21962 top level 256 path var/lib/lxc ID 270 gen 21966 top level 256 path var/lib/lxc/ubuntu-test/rootfs ID 271 gen 21960 top level 256 path var/lib/lxc/ubuntu-test/rootfs.fresh-install ID 272 gen 22066 top level 256 path .snapshots/backup_2014-01-24 ID 279 gen 22382 top level 256 path testvol ID 280 gen 22382 top level 256 path test-snap # sudo btrfs send /test-snap > /dev/null At subvol /test-snap ERROR: open @/test-snap failed. No such file or directory
Here's a "me too". Ubuntu by default does an install on btrfs with root stored on the subvolume @ and /home stored on @home. Newer versions of btrfs send refuse to send snapshots stored beneath / or /home/ as described. Kernel version appears to be irrelevant; it's the btrfs-progs version. Btrfs send was working properly in 3.11, 3.12, and 3.14 before upgrading the btrfs-tools package; after upgrading the package to the newest in Debian Sid (3.12-1) the described behavior appeared (and occurs regardless of kernel version). Note that btrfs send DOES still work properly for filesystems mounted directly rather than as subvolumes; for example I have an entirely separate btrfs filesystem mounted to /data and btrfs send from /data/.snapshots works fine with the newer version of btrfs-progs. As a workaround, it's also possible to simply mount the root filesystem directly and send snapshots from there: you@box:~$ sudo mount /dev/sda1 /mnt/test you@box:~$ cd /mnt/test/@/.snapshots you@box:~$ sudo btrfs send snapshot-name | pv > /dev/null The above will work as expected. Having to do that to send a snapshot, though, is definitely sub-par - you have to be wary of locate database blowing up and all sorts of other potential weirdnesses, not to mention some ueless cluser with sudo possibly going "what's all this crap under /mnt/test/@? DELETE!", etc.
This bug has been reported earlier on the mailing list (http://www.spinics.net/lists/linux-btrfs/msg29564.html) and has received a fix from Wang Shilong called "Btrfs-progs: avoid using btrfs internal subvolume path to send". This patch is in the integration branch of btfrs-progs official git repository (meant to become v3.13). Alternatively the workaround given by Jim Salter is the way to go with current progs. In his example i think the 'cd' is not required and one can also type: btrfs send /mnt/test/@/.snapshots/snapshot-name ...
Ok, thanks. I can confirm that the problem is fixed with the commit from Wang Shilong on the integration branch.