-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NULL deref in vn_rdwr() #447
Comments
There was a small vn_rdwr() fix made after 0.6.0-rc6 was tagged to handle 'zfs send' with a file target but you bug does look different, openzfs/spl@f3989ed . We'll certainly try and reproduce this but you might also want to try cherry-pick this fix until 0.6.0-rc7 is tagged. |
Brian, BUG: unable to handle kernel NULL pointer dereference at (null) Any advice? |
Try a clean check of the latest spl/zfs master branches. I've heard of no other reports of send/recv being broken. |
I cloned spl and zfs from git this morning, built/installed RPM's (--force), rebooted, did a recursive snapshot on a pool's filesystems, and did a recursive send/recv from that pool to another, and did not get any oopses. I'll sleep better tonight having a backup! |
Excellent! Let's call it fixed! |
Follow up from openzfs#404 and openzfs#422 where we used an iterator fold() where we really wanted to use reduce().
Currently, zcache devices are automatically expanded when the agent starts. This commit adds that ability to expand zcache devices while the agent is running, with the new `zcache expand DISK` subcommand. Note that we still auto-expand on open. In the future we'll make the appstack use `zcache expand`, and then we can remove the auto-expand code.
This was triggered by:
zfs send -v storage@backup | zfs recv -v backup/storage
I have rc6 with the two commits for #287 applied.
The text was updated successfully, but these errors were encountered: