I totally understand wanting to have encrypted dumps.

However, the current designs of dump and encryption are incompatible.  
Specifically: when dumping we do not modify any ZFS data structures; instead we 
just overwrite pre-allocated space.  Therefore dump doesn't have checksums, 
doesn't modify indirect blocks, and doesn't write out a TXG.  Encryption 
requires recording the IV in the block pointer, in the indirect block, which 
requires writing out a TXG.

We could implement encrypted dump in a different way than normal encryption, 
but have the administration seamlessly integrate with the current encryption.  
For example, we could record the IV (or IV's - and MAC) at the end of the dump, 
inside the dump zvol itself (in its data blocks, not the block pointers).

Until a special case encrypted dump is implemented, I think it would be 
dangerously confusing to automatically ignore an inherited `encryption=on` 
setting on a dump zvol.  I could see the argument for allowing unencrypted 
datasets under encrypted datasets, but if we do that we should allow it in 
general, not just for dump.

I would suggest that for now, we keep the current semantic (no unencrypted 
datasets under encrypted datasets).  If for Joyent's use case, they are OK with 
unencrypted dump, but need encryption set at the top of the pool, I'd suggest 
that an exception be added to the Joyent/SmartOS code to allow this (and 
hopefully @tcaputi or I can point you to the right place to do that or provide 
a patch).

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