I've subsequently had the panic I noticed happen on creation of an encrypted zvol without the `checksum` property set, so I suspect it's not just a result of that.
After hacking around that panic the way I outlined above (still not sure if it was a great idea, but it lets me consistently make zvols, and they seem to work?), I managed to create an encrypted zvol and give it to `dumpadm -d` to set it as a dump device. This produced no errors and `dumpadm` succeeded. Then I made the system dump (with `uadmin 5 1`) and brought it back up again, and thereafter it panics as soon as savecore comes up to look at the dump device (with message `panic message: unencrypted block in encrypted object set 572`, which seems within expectations given how dumping works). I think this might be two problems, not one: 1. fixing the panic on zvol creation (or finding it's the result of something stupid I did while merging/setting up my test env); and then 2. wanting to change the code so that `dumpadm -d` doesn't succeed on encrypted zvols (to prevent them being filled up with unencrypted blocks like this). I'm not sure they're related. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/124#issuecomment-321434711 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T1625245905c55186-Mc809bb7f13e004755959e651 Powered by Topicbox: https://topicbox.com
