NAS-141754 / 26.0.0-RC.1 / Make ZFS deduplication incompatible with the PERFORMANCE tier (by anodos325) (#19483)
Deduplicated datasets are excluded from tiering: they report a null
tier, and dataset_set_tier and rewrite_job_create reject them.
Enabling dedup (ON/VERIFY) is refused only when a dataset's data is on
the SPECIAL vdev, i.e. the PERFORMANCE tier (special_small_blocks > 0).
REGULAR datasets, volumes, and pools without a SPECIAL vdev may be
deduplicated freely.
Original PR: https://github.com/truenas/middleware/pull/19336
---------
Co-authored-by: Logan Cary <logan.cary at ixsystems.com>
lang/go126: Update to 1.26.7
Changes:
go1.26.7 (released 2026-08-19) includes fixes to the net/http package.
MFH: 2026Q3
(cherry picked from commit 466c3d8ebd2255c98a5461d168e0875f304d9d44)
lang/go125: Update to 1.25.14
Changes:
go1.25.14 (released 2026-08-19) includes fixes to the net/http
package.
MFH: 2026Q3
(cherry picked from commit 578f1cec0b2270176a2da96cf87a0ddde2eb46fc)
lang/go127: Add go 1.27
Changes:
Go 1.27 now supports generic methods: a method declaration may declare
its own type parameters. This widely anticipated change allows adding
generic functions within the namespace of a particular data type where
before one had to declare such functions with a scope of the entire
package.
A key in a struct literal may now be any valid field selector for the
struct type, not just a (top-level) field name of the struct.
Function type inference has been generalized to apply in all contexts
where a generic function is assigned to a variable of (or converted
to) a matching function type.
[profile] hoist length check before use of pointer (#217109)
If a truncated profile is passed into this endpoint (say, 1 byte), we
unconditionally do `((__llvm_profile_header
*)ProfileData)->BinaryIdsSize`, which reaches outside of the `char`
array passed to this function.
Hoisting the check prevents the out-of-bounds read.
[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors
getVectorTypeForAlloca() peeled nested ArrayType and one inner
FixedVectorType, but stopped at any StructType. An alloca of an array of
structs was therefore rejected with "Cannot convert type to vector" and
fell back to scratch, even when the struct was a trivial wrapper around a
scalar.
Peel structs too, but only when every field has the same type and the
struct has no padding, so flattened elements keep the byte offsets the
surrounding index arithmetic assumes. Structs with differing field types
or with padding are left alone.
Simplify logic via suggestions from PR feedback. Add additional test cases, make tests a bit more complex so they don't fold into simple store of constant
