> 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
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