In the case where ZFS support dedup capability later, what will be the impact on your crypto? On Performance and capacity aspect? What about ZFS compression too...crypt apply before or after compression. What about ZFS send/receive with key management integration? -- This message posted from opensolaris.org
Jean Dion wrote:> In the case where ZFS support dedup capability later, what will be the impact on your crypto?I''m not in a position to answer crypto and dedup integration questions at this point.> What about ZFS compression too...crypt apply before or after compression.Compression is before Encryption. Decryption is before Decompression. So basically they worked together.> What about ZFS send/receive with key management integration?The ZFS send stream is at the DMU layer and is currently sent uncompressed even for compressed datasets. The same will be true for encrypted datases. This is because the layer that does the ZFS stream is above the ARC which only stores decrypted and uncompressed buffers. This means that when a replication stream is sent for an encrypted dataset it will be sent in the clear. However the encryption properties will be sent and this results in a new set of data encryption keys being created for the datasets (filesystems) on the receiving side. If your key is prompted for on the sending side then ''zfs receive'' will prompt you for a new wrapping key otherwise the wrapping key must be available at the location pointed to in the keysource property (which is past to the receiver unchanged). So basically you still need to provide transport security between the ''zfs send'' and ''zfs receive'' eg ''zfs send -R store at snappy | ssh remote zfs recv -d'' -- Darren J Moffat