Potential problems with ZFS native encryption and replication?

[Juan Manuel Palacios]

Hi everyone,

I just saw this issue being posted today to OpenZFS' GitHub issue tracker, https://github.com/openzfs/openzfs-docs/issues/494, which references several discussions, some of them years long, about potential data corruption issues when using ZFS native encryption and replication, if I'm understanding correctly. And with such a combination being so common among TrueNAS users, from what I've seen, I thought it'd be pertinent to get some input and/or official position from iX on the topic.

For the record, I've been using native encryption and replication to two different pools, for several datasets, over a couple of years already, and I've not once experienced any problems, nor have I seen any scrub error reports for my pools as what's shown in those discussions, but it'd still love to hear from iX about what their experience with this particular combination of features has been, if they have official recommendations for or against them, etc.

Thank you!

 

[Ericloewe]

It's not a simple subject, unfortunately. It's very easy to dismiss this or that report as "clueless user #246 wasting our time", for good reason, but sometimes they're not merely a clueless user.

For the record, I've been using native encryption and replication to two different pools, for several datasets, over a couple of years already, and I've not once experienced any problems, nor have I seen any scrub error reports for my pools as what's shown in those discussions

I expect this is the experience in most cases. Given the added complexity, I'm sure there are weird edge cases that have been overlooked, and that's a crappy situation to be in for something that is not going to see ubiquitous use. Hell, just the other day that bug with the hole reporting was found to have been lurking around without apparently ever having had much impact, despite how serious it sounded.

 

[Arwen]

Sounds like an opportunity for the OpenZFS team to write up a new test case that can demonstrate the problem(s). One of the things I like about ZFS is that changes must include;

• Code, (if any)
• Documentation for the code in the source file(s), (if there was code)
• Documentation updates,(like manual pages), (if a change in usage is made, or a new feature added)
• And last, but NOT LEAST, an update or creation of an automated test procedure for any change or new feature

This last can be tricky if the feature works most of the time, (see recent hole bug). But, it appears from reading the GitHub Issue, that sending and receiving encrypted data with unencrypted datasets is a known failure conditions. So, something we can both test and work to resolve.

Having a usable test case may not catch every permutation of the various bugs involved. Yet is is a start. We keep adding test cases as we find reasons for adding them.