> 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:
Powered by Topicbox: https://topicbox.com

Reply via email to