Re: FreeBSD guest online disk resize

16.0-CURRENT worked! Going to try 15.1-PRERELEASE


root@freebsd:~ # gpart show
=> 34 20971446 nda0 GPT (10G)
34 448 1 freebsd-boot (224K)
482 66584 2 efi (33M)
67066 2097152 3 freebsd-swap (1.0G)
2164218 18807262 4 freebsd-zfs (9.0G)

root@freebsd:~ # nvmecontrol devlist
nvme0: bhyve-NVMe
nvme0ns1 (10240MB)
root@freebsd:~ # nvme0: async event occurred (type 0x2, info 0x00, page 0x04)
uma_zalloc_debug: zone "malloc-256" with the following non-sleepable locks held:
exclusive sleep mutex CAM device lock (CAM device lock) r = 0
(0xfffff800049e2cd0) locked @ /usr/src/sys/cam/cam_xpt.c:2238
stack backtrace:
#0 0xffffffff80c5583c at witness_debugger+0x6c
#1 0xffffffff80c57139 at witness_warn+0x4b9
#2 0xffffffff80fae064 at uma_zalloc_debug+0x34
#3 0xffffffff80fadbb7 at uma_zalloc_arg+0x27
#4 0xffffffff80bac02d at malloc+0x7d
#5 0xffffffff80b0625d at g_post_event+0x6d
#6 0xffffffff803b2fd2 at ndaasync+0x192
#7 0xffffffff803aa16a at xpt_async_process_dev+0x1ba
#8 0xffffffff803a8fbc at xptdevicetraverse+0x9c
#9 0xffffffff803a8d64 at xpttargettraverse+0x74
#10 0xffffffff803a587a at xpt_async_process+0x26a
#11 0xffffffff803a60f0 at xpt_done_process+0x3e0
#12 0xffffffff803a8425 at xpt_async_td+0xe5
#13 0xffffffff80b8a5d2 at fork_exit+0x82
#14 0xffffffff8110f7ee at fork_trampoline+0xe
GEOM_PART: nda0 was automatically resized.
Use `gpart commit nda0` to save changes or `gpart undo nda0` to revert them.

root@freebsd:~ # nvmecontrol devlist
nvme0: bhyve-NVMe
nvme0ns1 (20480MB)
root@freebsd:~ # gpart show
=> 34 41942966 nda0 GPT (20G)
34 448 1 freebsd-boot (224K)
482 66584 2 efi (33M)
67066 2097152 3 freebsd-swap (1.0G)
2164218 18807262 4 freebsd-zfs (9.0G)
20971480 20971520 - free - (10G)

root@freebsd:~ # gpart resize -i 4 nda0
nda0p4 resized
root@freebsd:~ # gpart show
=> 34 41942966 nda0 GPT (20G)
34 448 1 freebsd-boot (224K)
482 66584 2 efi (33M)
67066 2097152 3 freebsd-swap (1.0G)
2164218 39778782 4 freebsd-zfs (19G)

root@freebsd:~ # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 8.50G 2.92G 5.58G - - 0% 34% 1.00x ONLINE -
root@freebsd:~ # zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 8.50G 2.93G 5.57G - - 0% 34% 1.00x ONLINE -
nda0p4 8.97G 2.93G 5.57G - - 0% 34.4% - ONLINE -
root@freebsd:~ # zpool online -e zroot nda0p4
root@freebsd:~ # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 18.5G 2.93G 15.6G - - 0% 15% 1.00x ONLINE -
root@freebsd:~ #

On Thu, May 7, 2026 at 5:37 PM Warner Losh <[email protected]> wrote:
>
> Great! But if you are downloading an image, you could download
> https://download.freebsd.org/snapshots/VM-IMAGES/15.1-PRERELEASE/amd64/Latest/FreeBSD-15.1-PRERELEASE-amd64-zfs.raw.xz
> and it will tell me if I've overlooked anything needed for 15.1 release.
>
> Warner
>
> On Thu, May 7, 2026 at 2:23 PM Alexandre Biancalana <[email protected]> wrote:
>>
>> I'm giving a try with
>> https://download.freebsd.org/snapshots/VM-IMAGES/16.0-CURRENT/amd64/Latest/FreeBSD-16.0-CURRENT-amd64-zfs.raw.xz
>>
>> On Thu, May 7, 2026 at 5:19 PM Alexandre Biancalana
>> <[email protected]> wrote:
>> >
>> > My question is if i need to pull any additional patch and build the kernel or anything else.
>> >
>> > On Thu, 7 May 2026 at 17:04 Warner Losh <[email protected]> wrote:
>> >>
>> >> That's necessary, but not necessarily sufficient. If it works there, it might work in 15. If it doesn't work there, it won't work in 15.
>> >>
>> >> Warner
>> >>
>> >> On Thu, May 7, 2026 at 1:59 PM Alexandre Biancalana <[email protected]> wrote:
>> >>>
>> >>> I can test it, getting 16-CURRENT vm image is enough?
>> >>>
>> >>> On Thu, 7 May 2026 at 13:53 Warner Losh <[email protected]> wrote:
>> >>>>
>> >>>> I've not had a chance to test this yet, and it's getting late in the game. It's my belief that I MFC'd everything, but I've not had time to test it out.
>> >>>>
>> >>>> Can someone here test the scenarios that failed before on stable/15?
>> >>>>
>> >>>> Warner
>> >>>>
>> >>>> On Sat, May 2, 2026 at 5:31 AM Alexandre Biancalana <[email protected]> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>>  There’s an idea in which version outside current it will be available?
>> >>>>>
>> >>>>> On Tue, 20 Jan 2026 at 08:35 Alexandre Biancalana <[email protected]> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, 26 Nov 2025 at 00:42 Warner Losh <[email protected]> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Mon, Nov 17, 2025 at 3:16 PM Chuck Tuffli <[email protected]> wrote:
>> >>>>>>>>
>> >>>>>>>> On Mon, Nov 17, 2025, at 12:49 PM, Alexandre Biancalana wrote:
>> >>>>>>>>
>> >>>>>>>> On Mon, Nov 17, 2025 at 5:25 PM Warner Losh <[email protected]> wrote:
>> >>>>>>>> >
>> >>>>>>>> > I have a branch cooking that listens to the namespace resize and do the size changes to geom. Later this week.
>> >>>>>>>>
>> >>>>>>>> Great news ! Thank you Warner !
>> >>>>>>>>
>> >>>>>>>> Until there, any workaround so I don't need to reboot the machine to
>> >>>>>>>> resize the disk ?
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Warner
>> >>>>>>>>
>> >>>>>>>> Happy to poke at this if it would help. If so, which branch?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I'm terribly sorry, but I've fallen two weeks behind on my email. Happily, at least in this case, this means that I've committed changes to main that address this issue by calling the right resize functions for geom when we get namespace change events from the AENs we post to the drive. I missed this kind offer of help, so hopefully it was done correctly so your poking around at it reveals nothing broken. But if it does turn up something amiss, please let me know.
>> >>>>>>>
>> >>>>>>> Warner
>> >>>>>>
>> >>>>>>
>> >>>>>> Amazing ! Thank you!
>> >>>>>> Any chance that it could be MFC ?