Ich habe im illumos-gate-Quellcode selbst nachgesehen (nicht nur in der Mailingliste-Diskussion von damals) – und das Ergebnis korrigiert meine letzte Antwort in einem wichtigen Punkt.
In usr/src/uts/common/fs/zfs/dsl_crypt.c (aktueller master-Branch) finden sich exakt die Kompatibilitäts-Mechanismen, die OpenZFS 2018 eingeführt hat:
c
boolean_t
dsl_dir_incompatible_encryption_version(dsl_dir_t *dd)
{
...
return (version != ZIO_CRYPT_KEY_CURRENT_VERSION);
}
mit dem Kommentar "We don't support receiving old on-disk formats. The version 0 implementation protected several fields in an objset that were not always portable during a raw receive." Und in usr/src/uts/common/sys/fs/zfs.h gibt es die passenden Errata-Konstanten:
ZPOOL_ERRATA_ZOL_6845_ENCRYPTION – das ist exakt der Fix aus OpenZFS-PR #6864 (der 2018 das Format gebrochen hat)
ZPOOL_ERRATA_ZOL_8308_ENCRYPTION – ein weiterer, späterer Kompatibilitäts-Fix (OpenZFS-PR #8308, "mixed raw/non-raw sends")
Zusätzlich existiert der Tunable zfs_disable_ivset_guid_check, explizit dokumentiert für Kompatibilität mit älteren OpenZFS/ZoL-Verschlüsselungs-Streams ohne IVset-GUID.
Heißt konkret: meine Aussage von eben war veraltet. Der Mailingliste-Thread mit Jason Kings Erklärung ("illumos nutzt noch das alte, inkompatible Format") stammt aus der Frühzeit des illumos-Encryption-Ports (~2019). Der aktuelle illumos-gate-master-Branch hat die relevanten OpenZFS-Formatfixes seither offenbar nachgezogen – illumos nutzt jetzt dieselbe ZIO_CRYPT_KEY_CURRENT_VERSION und dieselbe Versions-/Errata-Logik wie aktuelles OpenZFS. Auf Code-Ebene sieht das nach echter Format-Kompatibilität aus, nicht mehr nach dauerhaftem Bruch.
Einschränkung, die ich nicht wegargumentieren will: das GitHub-Issue #13301 (SmartOS/illumos → Linux Mount-Fehler) ist neueren Datums und weiterhin offen/ungeklärt. Das könnte heißen, dass (a) die konkret verwendete SmartOS/illumos-Distribution nicht auf aktuellem illumos-gate-master basiert, (b) es sich um einen engeren Spezialfall handelt (z.B. genau die IVset-GUID- oder Mixed-Send-Problematik, die die genannten Tunables/Erratas ja gerade adressieren sollen, aber evtl. nicht in jeder Konstellation greifen), oder (c) schlicht noch nicht jeder betroffen Nutzer die neuere illumos-Version einsetzt. Ich kann aus dem Quellcode allein nicht mit Sicherheit sagen, dass ein zfs send --raw/receive zwischen aktuellem illumos und aktuellem OpenZFS heute in der Praxis garantiert klappt – nur, dass die dafür nötige Kompatibilitätslogik im Code vorhanden ist. Für produktiven Einsatz (Replikation zwischen deinem napp-it cs/OpenZFS-Windows-Member und einem illumos/OmniOS-Member) würde ich das vor dem Verlassen auf die Doku einmal mit einem echten Testdataset ausprobieren.
Sources:
illumos-gate/dsl_crypt.c (master)
illumos-gate/sys/fs/zfs.h (master)
Encrypted dataset created under current SmartOS/Illumos cannot be mounted on Linux · Issue #13301 · openzfs/zfs
Detect and prevent mixed raw and non-raw sends · Pull Request #8308 · openzfs/zfs
