Comment 3 for bug 1348430

I had this problem as well, and my situation was a little more complicated to use the workaround.

My subvolume that was being snapshotted for 'btrfs send' to use was at the top of the hierarchy - there WAS no parent. But BTRFS always has a parent, so there is still a workaround.

My situation:

root@diskybiz:~# btrfs subv list /x
ID 258 gen 13525 top level 5 path home
ID 259 gen 13521 top level 5 path backups
ID 553 gen 1724 top level 5 path home/@snap-20140811-082041
ID 621 gen 13524 top level 5 path home/backup001

As you can see, the very top of the hierarchy is ID 258 or /home. I wanted to use that snapshot at ID 621 for my 'btrfs send' command. I had to determine the parent of the ID 258 subvolume, which I did by "btrfs subv show /home" and looking at the "Parent:" line. This happens to be the same as the "top level" number shown in teh "btrfs subv list", but I wasn't sure that was a subvolume ID, so I went this extra step.

Then I just mounted another mountpoint for my BTRFS filesystem like this:

root@diskybiz:~# mount -o subvolid=5 /dev/sdc1 /x

That made the root of the filesystem visible on /x. Then I could do my 'btrfs send' like so:

root@diskybiz:~# btrfs send /x/ > /root/home-backup-20141001.btrfs

I hope this helps someone.