In the following feature request, someone asked for an easy method to shrink the boot-pool device:
Thinking about it, I wonder if the feature@device_removal could be used for that purpose. Basically:
Save the configuration off TrueNAS server
Verify you have console access to TrueNAS server
Verify that the existing usage of boot-pool is small enough to fit on the new device
Add the smaller device as a Stripe to the boot-pool
Enable the feature@device_removal on the boot-pool
Remove the larger device from the boot-pool
Wait until data migrated, then shutdown TrueNAS server
Remove prior boot-pool device
Power up and see if it worked
Of course, the Grub might need to be installed on the new boot-pool device. And who knows if Grub’s understanding of ZFS includes feature@device_removal.
Next, I don’t know if it is a requirement that the destination storage needs to be as large or larger of the source for device removal. I would not think so, as ZFS creates a virtual device in the destination storage. But, it might make an interesting test.
Last, of course this is not the straight forward supported method of backup configuration, re-install to smaller boot device and restore configuration. Further, Enterprise users would almost certainly not use such a method.
So what do you think?
Crazy?
Something interesting to test?
Not something needed, nor something new users should attempt?
An interesting suggestion, but as I now have a working and much configured system with lots of data I’m reluctant to experiment. The save config, install smaller device, restore config is easy to do and understand if time consuming. As someone who knows nothing about ZFS I mistakenly assumed downsize cloning would be easy!
As far as I know, the sole requirement is that there’s enough space in the remaining vdevs to accept all data from the removed vdev.
But the shenanigans with the bootloader already make this process more complicated than backup configuration-install-load configuration.
The existing process, while it doesn’t seem like an intuitive process for someone who’s never seen it before, is already very easy. Personally don’t think there’s any major benefit to changing it.
Maybe I just can’t find it, but it would be good for there to be some process in the documentation hub that users can follow for boot device replacement.
If you have hot swap boot-pool device(s), change out can be done live.
This also supports Mirrored boot-pool, so if you have a system that needs high availability, you can Stripe in a smaller 2 disk Mirror.
Oh, and there is one disadvantage:
The pseudo virtual device in the boot-pool takes up RAM for its indirect table. And this will continue until all the data is deleted out of the pseudo virtual device. (Updates should be written to real virtual device members.)
