Upgrading from 14.3 to 15.0

Welcome to ZFS snapshots and clones :) Very very simplistic, size of snapshots are related to "deltas" (think refcounting). Space is not reclaimed until nothing references the blocks.
Boot Environments are a combination of snapshots and clones, so they consume space. Space is not released until all references to it are released. freebsd-update by default automatically creating new BEs can make one run out of space and the user doesn't understand why. Remembering that freebs-update creates a new BE is the important part.

In general, one can safely (usually) bectl destroy -o all BEs except for the one that has "N/R/NR" on it.
 
mer you specified the -o switch, I never used it. Manpage states that flag "may be specified to destroy the origin as well", what mean? Is it safe to use it and I get more free space?
 
freethread said:
mer you specified the -o switch, I never used it. Manpage states that flag "may be specified to destroy the origin as well", what mean? Is it safe to use it and I get more free space?
Click to expand...
Snapshots and clones. Technically a Boot Environment is a clone; a clone is a read/write off a snapshot. So, you have a dataset, you create a snapshot, then you create a clone off that snapshot. Specifying "-o" means "deleting the Boot Environment means delete the clone, adding -o means also delete the snapshot".

So my understanding is yes specifying "-o" is safe and will fully reclaim space.
I believe that the default on bectl destroy have changed: at one point it did not automatically do -o but it may have changed so that -o became the default. I can never remember when the change occured so I always specify it.
 
siealex said:
Code: 
root@freebsd:/home/alex # bectl list
BE                                Active Mountpoint Space Created
14.1-RELEASE-p5_2024-12-03_212249 -      -          17.3M 2024-12-03 21:22
14.1-RELEASE-p6_2024-12-03_212829 -      -          1.50M 2024-12-03 21:28
14.1-RELEASE_2024-10-17_014001    -      -          417M  2024-10-17 04:40
14.2-RELEASE-p1_2025-02-23_014349 -      -          1.29G 2025-02-23 01:43
14.2-RELEASE-p2_2025-04-08_034820 -      -          66.4M 2025-04-08 03:48
14.2-RELEASE-p2_2025-04-10_231051 -      -          433M  2025-04-10 23:10
14.2-RELEASE-p3_2025-06-07_152841 -      -          2.64M 2025-06-07 15:28
14.2-RELEASE_2024-12-03_213019    -      -          1.61M 2024-12-03 21:30
14.2-RELEASE_2025-01-30_160358    -      -          176M  2025-01-30 16:03
14.3-RELEASE-p1_2025-08-16_120621 -      -          6.79G 2025-08-16 12:06
14.3-RELEASE-p2_2025-09-21_190424 -      -          323M  2025-09-21 19:04
14.3-RELEASE-p3_2025-10-02_121303 -      -          244M  2025-10-02 12:13
14.3-RELEASE-p4_2025-10-22_202437 -      -          1.64G 2025-10-22 20:24
14.3-RELEASE-p5_2025-11-28_162053 -      -          287M  2025-11-28 16:20
14.3-RELEASE_2025-06-07_153037    -      -          2.19M 2025-06-07 15:30
14.3-RELEASE_2025-07-04_040653    -      -          7.73G 2025-07-04 04:06
250122-000444                     -      -          176M  2025-01-22 00:04
default                           NR     /          91.6G 2024-10-17 04:28
Click to expand...
Yeah, this can happen if you have been diligently updating and upgrading with freebsd-update(8) a lot. Kudos for keeping up! You've done so quite nicely.

One really quick way to clean up this mess; bectl list -H | cut -f1 -w | grep RELEASE | xargs -n1 bectl destroy
Just make sure default is still set to NR before you do.
 
4755.jpg
 
You must log in or register to reply here.
Back
Top