On Tue, Jan 22, 2019 at 3:26 PM Eli V <eliventer@xxxxxxxxx> wrote: > > I seem to have it a deadlock trying out btrfs send & receive. Now I > haven't used btrfs send & receive much, so don't have much experience > with them. Anyways, bug report and stack traces: > https://bugzilla.kernel.org/show_bug.cgi?id=202383 This is the same you reported at: https://bugzilla.kernel.org/show_bug.cgi?id=199753 It just happens through a different path, unrelated to send/receive. You are running a 4.19.16 kernel, which doesn't have the fix [1]: $ git tag --contains 5ce555578e0919237fa4bda92b4670e2dd176f85 v4.20 v4.20-rc1 v4.20-rc2 v4.20-rc3 v4.20-rc4 v4.20-rc5 v4.20-rc6 v4.20-rc7 v4.20.1 v4.20.2 v4.20.3 v5.0-rc1 v5.0-rc2 v5.0-rc3 All the deadlock problems you reported are fixed by [1] and [2]. The second, related to the free space tree, is very recent and only on 5.0-rcs: $ git tag --contains a6d8654d885d7d79a3fb82da64eaa489ca332a82 v5.0-rc2 v5.0-rc3 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ce555578e0919237fa4bda92b4670e2dd176f85 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6d8654d885d7d79a3fb82da64eaa489ca332a82 > > Seems like the receive is hung as well as several kworkers. It's about > 1.2TB into a 9TB or so transfer onto a brand new pretty empty fs. This > is just a btrfs send snapshot, not an incremental. That was supposed > to come next. If this was an rsync based backup I'd just kill the > rsync process and restart it, not sure if there's a way to restart a > btrfs send receive, or if I'd have to delete the partially created > snapshot on the destination and restart the send. I guess I could just > use rsync to finish the copy of the initial snapshot as well before > using send | receive for the incrementals. Thoughts and options would > be appreciated, thanks. > > -Eli -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
