Hi, thanks for pointing it out. You are right: Sending the snapshot to a different btrfs fixes the problem. Interesting :) It's not what you would except, but for my purposes it's ok, because in the end I'll send it to a different btrfs. Felix On Thu, May 23, 2013 at 2:22 PM, Stefan Behrens <sbehrens@xxxxxxxxxxxxxxxx> wrote: > On Thu, 23 May 2013 13:51:59 +0200, Felix Blanke wrote: >> Hi everyone, >> >> I was trying the new send/receive feature today but can't make it work. >> >> These are the commands I was using: >> >> btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap >> btrfs send /mnt/data1/snapshots/testsnap | btrfs receive >> /mnt/data1/snapshots/testreceive/ >> >> This command never finishes. A 'ls /mnt/data1/snapshots/testreceive/ ' >> never finishes too. After killing the send/receive process one can see >> that the target subvolume was created but is empty. >> >> >> Sending the snapshot to a file and use this for receiving does work. >> What am I missing? >> > > That's a known design flaw in the btrfs send code. > 'btrfs send /subvol | sleep 666' > is an easier way to block the system. But it's interruptable if you > terminate the sleep task in this case. > > btrfs send blocks on the pipe while being in the kernel, the call chain > is like this: > btrfs_ioctl_send -> send_subvol -> full_send_tree -> changed_cb -> > send_cmd -> write_buf -> vfs_write -> pipe_write -> pipe_wait > > And full_send_tree() has called btrfs_join_transaction() before, thus > the whole file system and afterwards the system is blocked. > > You can avoid it if you receive to a different filesystem or if you > redirect the output of btrfs send into a file. In general, the output of > btrfs send must never be blocked or you are lost. > -- 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
