- Architectural Advancement: Now you can choose between encryption granted by SEDs and built-in ZFS encryption according to your goals & budget
- Operational Flexibility: Ability to perform scrubs, resilvers, and snapshots without loading decryption keys (“No-Key Operations”).
- Hardware Agnosticism: Eliminating the need for specialized, vendor-locked SED hardware in favor of commodity drives.
For years, the gold standard in the Open-E JovianDSS ecosystem was the use of Self-Encrypting Drives (SEDs). While effective, it tethered our security posture to specific hardware.
With the release of Open-E JovianDSS Up33, the landscape has shifted. By integrating native ZFS encryption, we now have a granular, software-defined method to secure data at the dataset or volume (zvol) level, decoupled from the underlying disk controller.
The Evolution: From SEDs to Native Encryption
Before Open-E JovianDSS Up33, securing an Open-E JovianDSS environment meant relying on the hardware layer. Support for SEDs – expanded significantly in the Up29r2 version of Open-E JovianDSS for single nodes and shared storage clusters, and then in Up30 for non-shared storage clusters, offered “instant” encryption with zero CPU overhead.
However, the really experienced admin will spot a trade-off: SEDs require specific, tested firmware. If the controller or the drive’s internal logic failed, you were at the mercy of the hardware vendor. Native ZFS encryption expands your range of encryption possibilities by letting you choose whether you want to use it through a hardware component or natively through the data storage software.
What Are The Pros of Native ZFS Encryption
Native ZFS encryption in Open-E JovianDSS Up33 utilizes the AES-256-GCM encryption algorithm by default. If you would like to, you can use another one. Furthermore, the addition of native ZFS encryption in our latest update grants you not only architectural freedom, but also a bunch of other advantages:
1. No-Key Maintenance Operations
ZFS native encryption is metadata-aware. This allows us to perform critical maintenance tasks, such as scrubs, resilvers, and taking snapshots, while the dataset or volume is unmounted and the keys are unloaded. You can verify data integrity and maintain redundancy without ever exposing the plain text.
2. Data Storage Efficiency Preserved
In the traditional approach, encrypting data at the block level renders compression useless (as encrypted data is incompressible). Open-E JovianDSS executes compression before encryption. This ensures you still get the TCO benefits of LZ4 (or other preferred compression algorithm) while maintaining a hardened security profile.
3. Hardware Agnosticism
You are no longer limited by the “Compatibility List” for specialized SEDs. You can deploy native encryption on standard, high-performance NVMe or SAS commodity drives, maximizing your ROI and avoiding vendor lock-in.
ZFS Encryption vs SED – Which One Is Better?
The real question isn’t strictly about which method is “superior,” but rather which one aligns with your specific architectural constraints and performance tiers. Generally, the divergence between SEDs and native encryption in Open-E JovianDSS comes down to resource allocation
SEDs perform encryption at the controller level, which offloads the cryptographic workload entirely from the host CPU – a critical factor if you are utilizing weaker processors or pushing extreme IOPS where every cycle counts. On the other hand, native Open-E JovianDSS encryption requires a more powerful CPU to execute the AES-256-GCM or other encryption algorithms. While this provides granular, dataset/volume-level control and lets you overcome vendor lock-in, it can impact system throughput if the processor isn’t sized correctly.
Ultimately, if your priority is raw performance and you have the budget for tested, specialized firmware, SEDs remain a robust choice. However, if you prefer to invest in higher-compute commodity nodes to avoid the premium cost of SED disks, native ZFS encryption offers the flexibility to secure your data at the file system.
The following table sums up the main trade-offs between hardware-bound and software-defined encryption within an Open-E JovianDSS environment:
| Feature | Self-Encrypting Drives (SED) | Native ZFS Encryption |
| CPU Overhead | Zero; processed on-drive. | Requires system CPU (AES-NI recommended). |
| Hardware Choice | Limited to Compatibility List/Specific Firmware. | Hardware agnostic; works with commodity drives. |
| Cryptographic Boundary | Disk Controller/Hardware Layer. | File System/Metadata-Aware Layer. |
| Cost Dynamics | Higher per-disk cost; lower CPU requirement. | Lower disk cost; requires a more powerful CPU. |
| Operational Flexibility | Hardware-dependent; key required for most tasks. | “No-Key” scrubs, resilvers, and snapshots. |
Native ZFS Encryption Explained
If you are managing mission-critical infrastructure where data sovereignty is non-negotiable, the native encryption is a wise move. It eliminates the “hardware tax” of SEDs while providing superior flexibility for off-site replication and cold-storage security. This doesn’t mean that SEDs are worse – they are just another approach that aligns with specific goals.
Ready to Enhance Your Data Storage Protection?
Download the Open-E JovianDSS Up33 update today and begin migrating your sensitive workloads to natively encrypted datasets & volumes. Also, feel free to read our full article on all new features in the latest version of Open-E JovianDSS!
And if you are not an Open-E JovianDSS user yet, feel free to download a 60-day free trial!
Leave a Comment