u/_gea_

https://github.com/openzfsonwindows/openzfs/releases
https://github.com/openzfsonwindows/openzfs/issues

** rc10

• Add FileCompressionInformation to enable query of on-disk compressed size
• Do some performance fixes to make things faster
• Hardlink deletion would hide all other hardlinks
• Fix deadlock in write path
• Prioritise HarddiskXPartitionY paths over hack path
• Add import --fix-gpt to correct NumPartitions=9 to NumPartitions=128.
• Fix up condvar and mutex
• Use User credentials, enabling zfs allow to work. Mix Unix and Windows permissions and hope for the best
• OpenZVOL unload bug fixes
• Fix spl_panic() call print and stack

So with Unix created GPT partitions, they use gpt.NumPartitions=9, this Windows does not accept, and Windows
computes gpt.checksum "as if" gpt.Numpartitions==128. So checksum mismatches, and partition table is ignored.

This is why OpenZFS uses path encoding of #partition_offset#partition_length#/path/to/device, saved into vdev->vdev_physpath.

This continues to work.

We added a new zpool import --fix-gpt which will rewrite gpt.NumPartitions=128, and recompute gpt.checksum. Since libefi already reads in the full GPT partition, we need not change anything else, and write it back out. This is left as a user option, as there could be partition usage I am unaware of. Who know if some legacy archs can only use fewer partitions? Or store microcode in the backhalf.

If GPT is written with gpt.NumPartitions=128, Windows will recognise the partitions, and create //?/HarddiskXPartitionY device objects, so we can import those directly, no need for special path. Success. We prioritise //?/HarddiskXPartitionY over #partition_offset#partition_length#/path/to/device - but it will try both.

Let's check for regression in this release.

Evaluate and report issues