panic / odd errors on dataset replicated via zfs send --raw #7317
Comments
|
No, the system is using typical desktop memory. |
|
The pool in question was created using and has only ever been used on the same version of zfs (although it has been used to receive datasets sent from older systems), so I presume the format changes aren't relevant to this issue? |
|
I just repeated the second test, and results were similar although slightly different: the incorrect value reported in the VERIFY3 line is different (so it doesn't seem as though an incorrect value is being copied from the source dataset), as are some of the entries in the stack trace: |
|
This issue is actually probably not caused by memory corruption. We have seen this issue a couple of times before (see issue #7117). We thought we had solved it, but if you are on the version of ZFS you say you are, then we may not have.... If you can reproduce this easily we may have a good shot at debugging it. Can you run |
|
@jh3141 |
|
@jh3141 any updates? |
|
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
and others
System information
Describe the problem you're observing
I've had two issues trying to use
zfs recvto verify a backup archive taken usingzfs send -wby receiving into the same pool that the data originated from, just with a different dataset name. The source dataset is encrypted via passphrase and contains approximately 250GB of data. Testing with a new dataset containing only test data did not replicate the issue.The first time I tried this, the commands I used were:
I received a kernel panic immediately after entering the passphrase.
I destroyed the test dataset and tried again using a snapshot, and with the commands in a pipe:
zfs send --raw storage/source@snap1 | zfs receive storage/test
zfs mount -l storage/test
This time there was no immediate panic, but when I tried to view the results I got an
Invalid Exchangeerror message fromls, and unmounting the dataset hung. A panic apparently occurred while I was attempting to shut the system down to remove the dataset (see log below)Describe how to reproduce the problem
Above commands apparently fail on every attempt with the given dataset (although testing takes a while so hasn't been done more than these two occasions), but attempts to reproduce with a new dataset have failed.
Include any warning/errors/backtraces from the system logs
The panic from the first attempt didn't get logged, and unfortunately the shot I tried to take of the screen with my phone camera was too blurry to be legible, but the failure appeared to have occurred in
spl_kmem_cache_free, which was called from a recursively-called function that may have beendbuf_sync_list. Unfortunately the message showing the cause of the failure scrolled off the top of my screen due to an extensive stack trace.The text was updated successfully, but these errors were encountered: