Discussion: Default Jail Creation & Removing Old "fetched" Releases

Hazimil

Contributor
Joined
May 26, 2014
Messages
172
A discussion (hopefully) regarding Jail creation and their dependencies upon releases (especially when upgrading Jails).

When you create a Jail, whether from the CLI or via the GUI, the Jail is created as a Clone of the release you specify. The benefit of this is that it only uses a small amount of space, preserving only the changing data, however I have since found that this does lead to problem later on if you have upgraded to a later release.

The way the default (Clone) Jail works, is that as it only preserves the changing data (like a snapshot), it leaves a dependency behind for the creation base release and all base releases upgraded to, for example:

On my server (FreeNAS v11.3-U1), I have three Jails ( iocage list), Syncthing has been upgraded from FreeBSD v11.1 to FreeBSD v11.3, and ClamAV/PlexMS have been upgraded from FreeBSD v11.2 to FreeBSD v11.3:
Code:
root@fruitbowl:~ # iocage list
+-----+-----------+-------+--------------+------------------+
| JID |   NAME    | STATE |   RELEASE    |       IP4        |
+=====+===========+=======+==============+==================+
| 18  | ClamAV    | up    | 11.3-RELEASE | 192.168.0.105/24 |
+-----+-----------+-------+--------------+------------------+
| 11  | PlexMS    | up    | 11.3-RELEASE | 192.168.0.103/24 |
+-----+-----------+-------+--------------+------------------+
| 12  | Syncthing | up    | 11.3-RELEASE | 192.168.0.106/24 |
+-----+-----------+-------+--------------+------------------+


As all my Jails have been upgraded to the FreeBSD v11.3 release, I thought it be useful to delete the old releases, as they are not needed (or so I thought), and to save space. The current list of base releases ( iocage list -r) on my server is:
Code:
root@fruitbowl:~ # iocage list -r
+---------------+
| Bases fetched |
+===============+
| 11.1-RELEASE  |
+---------------+
| 11.2-RELEASE  |
+---------------+
| 11.3-RELEASE  |
+---------------+


So I went ahead and tried to delete an old release, using the command iocage destroy -d -r 11.1-RELEASE, and after confirming the "Are you sure?" prompt, I got the following result:
Code:
root@fruitbowl:~ # iocage destroy -d -r 11.1-RELEASE

This will destroy RELEASE: 11.1-RELEASE

Are you sure? [y/N]: y

11.1-RELEASE has dependent jails (who may also have dependents), use --recursive to destroy:
  Syncthing
  auto-20200319.0000-2w
  auto-20200319.0000-2w


This led to some head scratching, and a trip to Google for help! I found the iocage documents regarding Jail creation, and this is where I found out about the fact Jails are created as a Clone by default. Further research led me to the GitHub pages for iocage, where I found the following:

Because of the use of zfs clone, in long term this can cause disk space lost and a mess with snapshots dependencies; in this link you can read about the possible related problem of using clones for basejails in more technical detail. Initially, clones can be "cheap" but in long term, moreover after a release upgrade, we can start to loose a lot disk space if we have a lot of jails.

Clones were really chosen for speed. The divergence for clone jail basejails should be minimal, really conf files and whatever you install. Since they switch bases. But it's not intuitive that these things would be applicable to them on upgrade (IE: Destroying an old RELEASE).

By default, jails are created as "Clone jails"; they take up less space initially but you will be stuck with a dependency on the "release". If you do not want this, you can create your jail as a "Base jail" or a "Thick jail".

The conclusion is that if we plan to just upgrade our Jails when new releases come out, then its best to create Jails as a Base Jail or Thick Jail, as this leaves no dependencies on old base releases. However, I cannot see an option for this within the GUI, also, I couldn't find if there was a way to convert a Clone Jail into a Base Jail or Thick Jail, otherwise we are going to have to delete and recreate our Jails via the CLI with the iocage create -r [RELEASE] -b or iocage create -r [RELEASE] -T commands.

Questions:
  1. What do people think of this?
  2. Should I do a feature request for Clone/Base/Thick Jail types in the GUI?
  3. Does anyone know if we can convert a Clone Jail into a Base Jail or Thick Jail?
  4. Whats the best way forward, Clone Jail, Base Jail or Thick Jail?
Yours
Jonathan
 

Hazimil

Contributor
Joined
May 26, 2014
Messages
172
A discussion (hopefully)

Well, I really hope this would be a discussion, as I thought others would be interested in this. No one?

J.
 

hertzsae

Contributor
Joined
Sep 23, 2014
Messages
118
I set my newish IOCage jails up with all data external, so I can easily delete them and start over. Therefore, it makes a little more sense for me to clone. I read your post and was curious to follow what more experienced and/or opinionated people would say.
 
Joined
Jul 10, 2016
Messages
521
There was a ticket to add the ability to create other jail types from the WebUI, but it was closed because it was too all encompassing/generic. The exact statement was:
The goal is not to have feature parity with CLI.
Lets please create specific tickets for things to consider implementing in the UI.
Ticket: https://jira.ixsystems.com/browse/NAS-100442

If you open a new ticket to e.g. add the ability to create a thick-jail from the UI, be sure to post it here, so it has some exposure and people can upvote it. I will. :D

BTW: It looks like you already did your homework on the different jail types with their respective pro/cons, but you may still find the following thread interesting:
https://www.ixsystems.com/community...ype-base-jail-vs-clone-which-to-choose.82639/
 

Hazimil

Contributor
Joined
May 26, 2014
Messages
172

glauco

Guru
Joined
Jan 30, 2017
Messages
524
3. Does anyone know if we can convert a Clone Jail into a Base Jail or Thick Jail?
As I was having the same itch to get rid of old releases, I have just successfully turned my clone jails into thick jails by exporting, destroying and importing them, like so:
Code:
setenv jail nextcloud
iocage stop $jail &&\
iocage export $jail &&\
iocage destroy -f $jail &&\
iocage import $jail &&\
zfs list -t all -o name,origin -r yourpool/iocage/jails/$jail &&\
iocage start $jail

How do you know if your jail is a clone or not?
By running command zfs list -t filesystem -o name,origin -r yourpool/iocage/jails , datasets with origins are likely clone jails.
By the way, I don't know why, but even after turning all my clone jails into thick jails, iocage destroy -d -r 11.1-RELEASE would still complain that some of my jails were depending on it.
So I exported those jails again so that I could re-import them later and ran the iocage destroy command but wierdly enough it complained that it couldn't find the first snapshot of the dependencies list.
So I went to the FreeNAS web UI, deleted all my snapshots and ran iocage destroy again, and this time it destroyed it! Same thing for 11.2-RELEASE, what a relief!
No more clone jails for me, except for quick experiments.
 

bal0an

Explorer
Joined
Mar 2, 2012
Messages
72
For me the destroy had to be recursive as I am taking jail/root snapshots every day.

Code:
set POOL=tank
set JAIL=bareos3
iocage stop $JAIL
iocage export $JAIL
iocage destroy -f --recursive $JAIL
iocage import $JAIL
zfs list -t all -o name,origin,clones -r /mnt/$POOL/iocage/jails/$JAIL
iocage start $JAIL
 
Top