[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ezjail] Roadmap for ezjail
Dirk Engling wrote:
Could someone maybe explain the sparse image concept a little better to
me in the instance of using
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
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.
* address the archive problems
* handle image jail file system inconsistencies more clever (fsck -y)
* address the /usr/share/skel issues
* include Philipps ZFS patch (did I just miss your feedback?)
* sparse image jails (probably with a cleanup function to counter
* 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
Regards and a good evening
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.
robert AT solidsolutions DOT net