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

Re: [ezjail] Roadmap for ezjail



Dirk Engling wrote:
Hello all,

although I do have little time at the moment, I still closely follow
this list and will address all archive issues soon. It is correct that I
shouldn't have put the archive feature into the release without more
tests. It has shown that my quick fixes were not as successful as they
should've been.

However, once I'm diving into the code again I'd like to take a look,
how to make the most of all the new shiny rc.d/jail features without
breaking ezjail on older systems. So here's a list of things I consider
worthy putting into a next release of ezjail. Feel free to add issues I
might have missed.

Bugfixes:
* address the archive problems
* handle image jail file system inconsistencies more clever (fsck -y)
* address the /usr/share/skel issues

Features:
* include Philipps ZFS patch (did I just miss your feedback?)
* sparse image jails (probably with a cleanup function to counter
fragmentation)
* include FIB routing
* nicknames for jails, i.e. you can skip the less specific parts of the
domain such as the TLD, as long as the more specific remaining part is
unique

Regards and a good evening

  erdgeist
Could someone maybe explain the sparse image concept a little better to me in the instance of using
it for a jail.

My understanding is that an option would be added when creating a jail to make it a sparse image specifying a max image size of lets say 20GB. The image file itself would only actually be the size of the data within the jail but could go up to 20GB. So the image file could be 6GB, and the file would grow as the data builds up inside.

So far am I on the right assumption?

Next I'm under the impression that data creation within sparse images is at a slower pace than a normally utilized disk. I know that other situations under the same idea such as like a vmware image that grows as more is used can be slow and inefficient. Can someone talk about the data handling in regards to this a tad?

I guess my final thinking is that if there were to be significant efficiency loss in using a sparse image with a rapidly growing image file, a jail that merely serves a function and needs little writing to disk would be highly ideal and maintain a small image.

Someone peruse my thinking and see if 1) I'm on the right track and 2) clarify any misinformation I have.

Thank you!

--
Robert Clemens
robert AT solidsolutions DOT net