On Tue, May 19, 2026 at 18:20:30 +0300, George Melikov wrote: > From: George Melikov <[email protected]> > > Signed-off-by: George Melikov <[email protected]> > --- > NEWS.rst | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/NEWS.rst b/NEWS.rst > index 2ecea251da..6ef55124a7 100644 > --- a/NEWS.rst > +++ b/NEWS.rst > @@ -25,8 +25,20 @@ v12.4.0 (unreleased) > > * **Improvements** > > + * storage: ZFS: Implement native volume resizing (since v11.7.0)
I presume that by the 'since v11.7.0 you mean commit 23a1eb0dc7f1c255ae6d857f78f5a6cf58b2dc5e: commit 23a1eb0dc7f1c255ae6d857f78f5a6cf58b2dc5e Author: George Melikov <[email protected]> Date: Thu Jul 24 17:34:03 2025 +0300 Storage: ZFS: implement `resizeVol` method to support native resize ZFS doesn't have thick allocations, every allocation is thin-provisioned, so resize operation is essentially a zvol size limit change v11.6.0-9-g23a1eb0dc7 right? In such case don't put it under the news for the 12.4.0. release, but to the corresponding one (and in a separate commit since it's not related to this release and this patch also has another hunk. > + > + The ZFS storage driver now supports ``resizeVol`` allowing online > + resizing of zvols via ``zfs set volsize``. Since ZFS is always > + thin-provisioned, resize is essentially a size limit change. > + > * **Bug fixes** > > + * storage: ZFS: Fix incorrect volsize and refreservation on zvol creation > + > + When creating a zvol, the ZFS driver listed all volumes in the pool and > + updated the new volume's size with data from the last volume in the list > + rather than the matching one. Now it correctly returns on valid one. > + > * esx/vmware: VMs are tracked under different UUIDs by default > > The VMWare-related drivers were using allegedly unique IDs for domains, > but > -- > 2.53.0 >
