[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ezjail] ZFS? [WAS] Re: Problem with "archive" command in 3.0b



Thanks for the feedback!

Graham Todd wrote:
> Philipp Wuensche wrote:
>> Philipp Wuensche wrote:
>>> More on monday.
>> Got to the server a bit earlier, so for the early adopters:
>> http://outpost.h3q.com/patches/ZFS-ezjail/
>>
>> Take a look at ezjail.conf, you need to set
>>
>> ezjail_use_zfs="YES"
>> ezjail_jailzfs="tank/jails"
>>
>> The jailzfs-filesystem will be mounted to the path set in ezjail_jaildir.
> 
> In some ways like this approach since it is a bit more generic than the
> what I have been doing: i.e. creating a directory to use as a mountpoint
> under the usual /usr/jails and then using: zfs set property="" to adjust
> the mount point of each zfs based jail's filesystem to /usr/jail/jailname
> ... (see my previous posts).
> 
> Your approach is simple and is more "all or nothing", correct?  I have a
> mix of zfs based jails and normal and image based jails. With your
> modifications and "ezjail_use_zfs" set, "ezjail-admin create jailname"
> would always create zfs based jails, right?.  

Thats right, its an all or nothing approach including basejail etc. in
ZFS too. I tried to think of implementing it in a mixed way, with the
possibility to still create directory based jails or still manage
basejail in a directory but this includes some problematic scenarios:

##

1. Scenario: directory based basejail and newjail, creating a ZFS jail

It could be possible to create a zfs based jail with that, but this
would not allow to use snapshot/send/recv/clone to create the data
inside the jails ZFS. So this needs to be taken care of by dump&restore.

It also includes your approach of creating a ZFS somewhere and adjust
the mountpoint property or create the symlinks in the ezjail directory.

In this scenario you are obviously losing some of the nicer features a
ZFS based basejail and newjail would bring, like snapshots on the
basejail before doing a ezjail-update -i, using compression on the
basejail to safe even more space and I/O on the disks, using snapshot on
newjail and creating the new jail with send/recv or maybe clone instead
of using dump&restore.

2. Scenario: ZFS based basejail and newjail, creating a directory based jail

Someone has ZFS and wants to create a directory based jail, obviously
this can also not be done via snapshot/send/recv/clone. So dump&restore
are needed again.

##

Conclusion:

Using ZFS in ezjail includes two different decisions to make: a) the
filesystem for the jails itself and b) managing basejail etc. in ZFS or
not.

So I guess it needs a "ezjail_basejail_ZFS" option too and the admin has
to make the decision if he wants ZFS to manage basejail/newjail with ZFS
features or not.
After that taking care of both scenarios and their interactions should
be manageble. This way it would be an all or nothing approach regarding
the base- and newjail stuff but allowing the user to use ZFS based jails
or not by implementing a new jail type.

Btw., my guess is, if someone manages basejail in ZFS he already uses
ZFS and there is no advantage of _not_ managing the jails in ZFS too. So
the second scenario is very unlikely and maybe I only need to take care
of the first!?

Its up for discussion!

> You get my support :) One thing interesting to explore when ZFS is used
> would be the implications for ezjail's basejail and symlink approach and
> features like zfs cloning. I'm not sure how a feature like cloning would
> effect updating a basejail and its children, managing flavours, etc. The
> "symlink to basejail" approach is very powerful, but cloning the basejail
> seems to create what looks a full traditional jail from the inside while
> still being efficient with disk space. ...

I played with that too. Problem is: if you mount a clone of the basejail
into the jail (could be read-only too) you are losing the ability to
update the basejail with one simple command as every clone is a seperate
filesystem. You could create a new clone of the updated basejail, but
this would include destroying and unmounting the old clone from the
running jail taking away the complete freebsd-userland during operation.
So you need to restart the jail when updating the basejail clone. Can be
done, don't know if I like it.

This feature would also not safe any space compared to the nullfs mount!
Nullfs already safes the most space possible. :-)

The only advantage would be: you can easily give jails a read-write
basesystem _and_ safe space if you would like to. Again, not sure if I
like the implications of that.

>>
>> I'm not sure if the script still works with ZFS disabled in ezjail.conf
> 
> Hmm do you mean inside rc.conf? I didn't notice any issue using
> ezjail-admin on a non ZFS enabled system *without* ezjail_use_zfs="YES"
> set.  

I meant in ezjail.conf, I haven't tested the ezjail-admin script with
the ZFS patch on a system without any ZFS. So I don't know if the
original ezjail-admin stuff (creating a directory, dump/restore basejail
etc.) still works. But if you have tested that and it still works, yay! :)

I suppose if ezjail.conf contains ezjail_use_zfs="YES" but rc.conf
> does not enable zfs then a meaningful error should be issued:  "If you
> wish to use ZFS features with ezjail, please enable ZFS on your system and
> create a ZFS heirarchy at the location indicated in your ezjail.conf
> ezjail_jailzfs="tank/jails". See [reference] for details on configuring
> zfs on your system".  ....

True, it should warn if there is no ZFS available or the zpool the
jail-filesystem is located on does not exist.

greetings,
philipp