zfs send/recv - 'invalid backup stream' on multiple receives #386
Comments
|
Interesting, and thanks for the concise test case. Did you happen to try this with OpenIndiana or Solaris Express too? We'll certainly look in to it. |
|
I can confirm that his bug does not exist in zfs-fuse for linux. |
|
Gunnar Beutner was able to come up with a patch for this. I tested it on my development device and so far it works exactly as intended. We're doing some more testing later this week; at this point I would consider this ready for official evaluation so that it can be committed and this bug closed. I will post back here if we encounter any problems while we are testing this patch. https://gunnar-beutner.de/files/0001-Fixed-invalid-resource-re-use-in-file_find.patch |
|
Gunnar gunning bugs down. Hell yeah. |
|
Fixed by spl commit openzfs/spl@763b2f3 |
File descriptors are a per-process resource. The same descriptor in different processes can refer to different files. find_file() incorrectly assumed that file descriptors are globally unique. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes ZFS issue #386
|
Gunnar, I believe you claim the $ for this one: http://twitter.com/#!/danfuhry/status/123173193564422146 |
The smp_mb__{before,after}_clear_bit functions have been renamed
smp_mb__{before,after}_atomic. Rather than adding a compatibility
function to handle this the code has been updated to use smp_wmb().
This has the advantage of being a stable functionally equivalent
interface. On many architectures smp_mb__after_clear_bit() expands
to smp_wmb(). Others might be able to do something slightly more
efficient but this will be safe and correct on all of them.
Signed-off-by: Turbo Fredriksson <turbo@bayour.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#386
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
If a merge completes when the zettacache is completely empty (no blocks allocated), we can hit a divide-by-zero in BlockAllocator::flush() when creating a log message. This is difficult to hit in practice since we wouldn't normally initiate a merge if there's nothing allocated. However, future work will make it possible for this to happen. This commit avoids the divide-by-zero by incrementing the divisor, which is typically very large, so the impact on accuracy is negligible.
Running two or more simultaneous zfs receive operations results in 'invalid backup stream'. A single receive seems to go through without issue, but when a second is run, the first instance errors out with 'cannot receive incremental stream: invalid backup stream' shortly after starting the second instance.
root@testServer:~# zfs send -R testPool/vol1@sshot1 | zfs recv -u testPool/vol1-test
cannot receive new filesystem stream: invalid backup stream
root@testServer:~# zfs send -R testPool/vol2@sshot1 | zfs recv -u testPool/vol2-test
cannot receive: failed to read from stream
The text was updated successfully, but these errors were encountered: