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