SOLVED understanding of iocage jail storage

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,477
Hey everyone,
I have multiple jails setup successfully in 11.2-RELEASE-U1.

I am just trying to better understand how the iocage mount jail storage works. This is what I understand happens when you create a mountpoint and according to the manual:

- the source is a dataset outside of the jail on the host system that the jail can access
- the target dataset is a dataset within the jail that is linked to the source dataset

I have successfully set this up but need a few clarifying points that I couldn't find direct answers to:
- Where is best practice to add the files. If you add files on the "source", are they replicated or just "linked" to inside the jail?
- Does this double count space on the pool because the same file is created in two locations (I guess not)?
- What happens if I delete something from the "target", does it also remove it from the "source" (and vice versa)?

If anyone has any resources that clears up these points, I would appreciate it! Thank you!
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
Source and Target are literally the same thing. There is no linking or replication.

You can add them in either place. If the jail is adding files it will as to it's path which is the Target path. If you are adding you will add to the source path because you shouldn't be accessing the jails path.

If you delete one is gone in the offer because they are the same.
 

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,477
Thanks for the clarification.

So best practice is to have any files you need within the jail to be mounted to an target outside the jail and then manipulated there. But any manipulation that is done will reflect on the file within there jail as well. Correct?

Where does the file reside on disk though? Does a file that is in a directory within the jail and mounted outside of the jail, is it taking up space in both places?

Thanks!
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
Thanks for the clarification.

So best practice is to have any files you need within the jail to be mounted to an target outside the jail and then manipulated there. But any manipulation that is done will reflect on the file within there jail as well. Correct?

Where does the file reside on disk though? Does a file that is in a directory within the jail and mounted outside of the jail, is it taking up space in both places?

Thanks!
You never have something mounted outside the jail like you are describing it. Everything is always outside the jail. Disk space is not affected, they are literally the same files, it can't use more space there is only 1 file.
 

Jailer

Not strong, but bad
Joined
Sep 12, 2014
Messages
4,977
Mounted storage is kind of hard to visualize. I'm very much a visual learner so I've tried to understand things visually whenever I can. Think of mounted storage as 2 separate rooms with an open door between them. The source would be the dataset (room) on your pool where the files are stored. The destination is the directory inside the jail (room) that you have access to in the jail. The mount point is a door that opens a direct pathway between the two that allows you to view and access the files from the destination in the jail via the mount point (door). When you are looking into the room that resides inside the jail (destination), or as you state manipulating files, you are actually looking through the door to the source and viewing and manipulating the files that reside there. When you remove the mount point the files are still residing on the source dataset but you are in effect closing the doorway between the source and destination and can no longer view them from the destination in the jail.

I hope that makes some sense as it's a really dumbed down version of how I look at mounted storage.
 

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,477
Mounted storage is kind of hard to visualize. I'm very much a visual learner so I've tried to understand things visually whenever I can. Think of mounted storage as 2 separate rooms with an open door between them. The source would be the dataset (room) on your pool where the files are stored. The destination is the directory inside the jail (room) that you have access to in the jail. The mount point is a door that opens a direct pathway between the two that allows you to view and access the files from the destination in the jail via the mount point (door). When you are looking into the room that resides inside the jail (destination), or as you state manipulating files, you are actually looking through the door to the source and viewing and manipulating the files that reside there. When you remove the mount point the files are still residing on the source dataset but you are in effect closing the doorway between the source and destination and can no longer view them from the destination in the jail.

This does make sense but doesn't this description run contradictory to what the manual says?
  • Source: is the directory or dataset on the FreeNAS® system which will be accessed by the jail. FreeNAS® creates the directory if it does not exist. This directory must reside outside of the pool or dataset being used by the jail. This is why it is recommended to create a separate dataset to store jails, so the dataset holding the jails is always separate from any datasets used for storage on the FreeNAS® system.
  • Destination: Browse to an existing and empty directory within the jail to link to the Source storage area. It is also possible to add / and a name to the end of the path and FreeNAS® automatically creates a new directory. New directories created must be within the jail directory structure. Example: /mnt/iocage/jails/samplejail/root/new-destination-directory.

It seems that the source is actually the directory inside the jail and the target is the dataset on the host. But the manual states the opposite. I have tried to have automated actions in the jail move files to that mounted directory outside the jail but it seems it only has access to the directories within the jai (which makes sense). So if this is the case, then the source is the directories within jails and the targets are the directories on the host system that is linked to the directories in the jail. Correct?

@Jailer your description does make sense about the door, but it just seems the source should be the dataset in the jail.

Related question:
- Couldn't one just avoid mount points and access storage directly in the jail and run scripts from the host system, moving, copy, etc files from that dataset in the jail to wherever they need to be (using /mnt/tank/iocage/jails/jailname/root/......etc)?

Thank you!
 
Last edited:

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
This does make sense but doesn't this description run contradictory to what the manual says?
  • Source: is the directory or dataset on the FreeNAS® system which will be accessed by the jail. FreeNAS® creates the directory if it does not exist. This directory must reside outside of the pool or dataset being used by the jail. This is why it is recommended to create a separate dataset to store jails, so the dataset holding the jails is always separate from any datasets used for storage on the FreeNAS® system.
  • Destination: Browse to an existing and empty directory within the jail to link to the Source storage area. It is also possible to add / and a name to the end of the path and FreeNAS® automatically creates a new directory. New directories created must be within the jail directory structure. Example: /mnt/iocage/jails/samplejail/root/new-destination-directory.

It seems that the source is actually the directory inside the jail and the target is the dataset on the host. But the manual states the opposite. I have tried to have automated actions in the jail move files to that mounted directory outside the jail but it seems it only has access to the directories within the jai (which makes sense). So if this is the case, then the source is the directories within jails and the targets are the directories on the hot system that is linked to the directories in the jail. Correct?

@Jailer your description does make sense about the door, but it just seems the source should be the dataset in the jail.

Related question:
- Couldn't one just avoid mount points and access storage directly in the jail and run scripts from the host system, moving, copy, etc files from that dataset in the jail to wherever they need to be (using /mnt/tank/iocage/jails/jailname/root/......etc)?

Thank you!
Source is the path outside the jail. Target is the path inside the jail. 100% positive on this and the manual is correct.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
Related question:
- Couldn't one just avoid mount points and access storage directly in the jail and run scripts from the host system, moving, copy, etc files from that dataset in the jail to wherever they need to be (using /mnt/tank/iocage/jails/jailname/root/......etc)?
Yes you can do this, it's a hack though. Also storing files in a jail is usually a bad design. Jails should be easy to rebuild at the drop of a hat, if you have all your data in there and the jail gets nuked you lose all your data.
 

Jailer

Not strong, but bad
Joined
Sep 12, 2014
Messages
4,977
Related question:
- Couldn't one just avoid mount points and access storage directly in the jail and run scripts from the host system, moving, copy, etc files from that dataset in the jail to wherever they need to be (using /mnt/tank/iocage/jails/jailname/root/......etc)?
But why go through all that hassle when you can very easily just mount storage and be done with it. Keep It Simple Sir.
 

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,477
Source is the path outside the jail. Target is the path inside the jail. 100% positive on this and the manual is correct.

Got this, yep that is what the manual says. Maybe I'm just getting hung up on the word "source" and "target" and are trying to equate them to difference scenarios when there is clearly an origination directory (in the case of replication, cp, mv, rsync, etc.) and a destination directory. I'm likely just looking at it a different perspective but both of your multiple comments help to clarify a different point of view, which was clearly taking in crafting the language of the manual.

I'm currently rethinking my jail storage strategy as I transition to iocage. This has helped, thanks.
 
Top