"pv" might help?

[illumos-gate] 18110 pciebus topo module caches snapshot-lifetime pointers in module-lifetime state -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18118 SCTP frees wrong-size, and needs to keep private options private -- Dan McDonald <danmcd⊙ei>

hrm.. so ptem->tvs_queue ends up with an apparently bogus (or at least wrong) queue_t

Is dataset encryption not being portable from ZOL across to illumos ZFS expected? Under OmniOS i consistently get an I/O error and a data error in the DMU vnode (dataset<0x0>) when trying to mount a dataset with aes-256-gcm set. The dataset was created and populated on my previous Alpine system. I reproduced the bug on the same pool by creating a dataset containing a single text file under the Alpine LiveCD, while an unencrypted

dataset with the same file is mountable as expected. The pool is a two mirror configuration initially created by the OmniOS installer and has only checksum=skein and compression=lz4 set, no upgrading, send/recv or unscheduled reboots done. No other ZFS errors show up anywhere on the system. I poked around a bit with zdb, but didn't find anything i can place with my limited experience.

I forgot to mention: On the Linux side everything seems to be fine. All data is accessible and running a scrub consistently clears up the data error.

yes

openzfs broke the on-disk format an in incompatible way early on

Can an encrypted dataset from illumos be accessed on Linux or is transfering the unencrypted data my only option?

not currently...

i have a patch that fixes things, but i've not had time to finish it

Probably not going to start compiling illumos now. Thanks anyways.

*sigh*

why do driver writers keep misusing driver.conf files

(making a property multi-valued where val[0] is for instance 0, val[1] instance 1, etc)

you can set a global or define per-instance values based on the hardware path

jbk: because nobody knows how that works and nobody spotted it in review

didn't the sun cluster source get released (officially) at one point?