Skip to content

Conversation

@wq9578
Copy link

@wq9578 wq9578 commented Nov 4, 2025

Due to incompatible formats, illumos ZFS cannot read OpenZFS datasets with native encryption.

This incompatibility should be mentioned to avoid unexpected results.

Due to incompatible formats, illumos ZFS cannot read OpenZFS datasets with native encryption.
@gmelikov
Copy link
Member

gmelikov commented Nov 4, 2025

I propose to add this note similar to edonr note (if you're ready to try):
f386276
c220891

Otherwise reader have to read everything to find this note.

implementations.

Due to incompatible formats, illumos ZFS cannot read OpenZFS datasets
with native encryption.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OpenZFS cannot read illumos either.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this report, it seems to be possible that way.

@wq9578
Copy link
Author

wq9578 commented Nov 4, 2025

I propose to add this note similar to edonr note (if you're ready to try): f386276 c220891

Otherwise reader have to read everything to find this note.

Maybe it is better to place the note in the general section instead of a footnote to only one filesystem, so users won't be surprised when starting with one filesystem and later find the footnote for the second system, not being able to use it then for their data.
The restriction of the statement should be placed right after: "Where all features that are used by a pool are supported by multiple implementations of OpenZFS, the on-disk format is portable across those implementations."

Also, I'm not familiar with Python, unfortunately.

@gmelikov
Copy link
Member

gmelikov commented Nov 4, 2025

Maybe it is better to place the note in the general section instead of a footnote to only one filesystem, so users won't be surprised when starting with one filesystem and later find the footnote for the second system, not being able to use it then for their data.

So, we'll need to note about all features in this case? That's the whole purpose of features - different OSes have different features. I mean - you usually check "if this OS supports encryption feature?", and if it has "Yes^2" (note link) then you'll propably want to see notes. Did I miss something?

The restriction of the statement should be placed right after: "Where all features that are used by a pool are supported by multiple implementations of OpenZFS, the on-disk format is portable across those implementations."

Indeed we may add note about "with explicit notes about support level if there's a difference".

What I mean - if we merge this PR as is - someday someone will inevitably miss such note and look only at feature matrix, and won't see this note.

Also, I'm not familiar with Python, unfortunately.

Got you, I'll try to add it later, in a week or so. I'll add you as a coauthor, if you don't mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants