![]() ![]() This does not mean that I am anti-cryptography. (Again, personal opinion, others will disagree.) In practice you're lying to ZFS just as badly as if you were using hardware RAID and adding a risk to the zpool integrity that is on a par with not using ECC memory. Until such time as the work is re-done for zfs 5000 or btrfs reaches maturity and functional parity, we're stuck with the current work-arounds.įreeNAS does not adhere to the ZFS architecture for cryptography but rather interposes a virtualization layer between the raw disk blocks and what zfs thinks are disk blocks. Unfortunately with the Oracle purchase of Sun that work did not make it to Open Source before Oracle slammed the door. If you want to see how easy it is look here: The devil-containing details are in the key management, as always with anything crypto-related. Consequently the way encryption is handled in Solaris 11 (and onwards) adheres to this philosophy since essentially encryption is managed as a "plug in" much the same way as compression and de-duplication. One of the design goals for ZFS was to abstract as much functionality away from the low level as possible. I'll stop credentialing now, since it won't make a difference anyway. ![]() These are the personal opinions of a professional systems architect who has worked with ZFS almost since its inception and under Solaris, OpenSolaris, OpenIndiana, FreeBSD, and FUSE (Linux, OS X). ![]()
0 Comments
Leave a Reply. |