> I'm guessing that this is probably not going to work, and should be blocked > off as a combination of properties (i.e. refuse to set encryption=on with > checksum=off)
We don't have `checksum=noparity` on Linux so I hadn't really thought about how this might apply. As is, the code SHOULD just not do extra checksum work, but it should still keep the cryptographic MACs and check them at decryption time. I'm not completely sure what `noparity` does in this situation that is preventing this, though. > But then we have the problem of what to do about the dump zvol. Would it be > possible to allow unencrypted children of an encrypted dataset at some point > in the future? I must admit I haven't understood the design well enough yet > to tell that for myself, sorry. The limitation that you can't create an unencrypted dataset under an encrypted one is a bit artificial. We did this so that a sysadmin couldn't easily "trick" a user into writing unencrypted data by adding an unencrypted dataset below their encrypted one. I'm not quite sure I completely understand the use case here, though. Could you create `pool/dump`, `pool/swap` and `pool/encrypted`? Is there a reason this data shouldn't be encrypted in the first place (even though it should only be used by the system)? -- 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-321132620 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T1625245905c55186-Md1dc84b623fabdc29f180740 Powered by Topicbox: https://topicbox.com
