<div dir="ltr">Thank you ver much for this explanation, I really appreciate it!</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><br></div><div><b style="font-family:arial;font-size:small"><font color="#666666">Marcel Sánchez Toledano</font></b><br></div><br></div></div>
<br><div class="gmail_quote">2014-08-30 16:25 GMT+02:00 Michael H. Warfield <span dir="ltr"><<a href="mailto:mhw@wittsend.com" target="_blank">mhw@wittsend.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2014-08-30 at 09:02 +0200, Marcel Sánchez Toledano wrote:<br>
> Hi again,<br>
><br>
<br>
> Anyone who knows about this can tell us something? I need some<br>
> information about this.<br>
<br>
</span>It's very hard to say much about it when you're comparing apples to<br>
oranges.<br>
<br>
To start off with, you're comparing a file system image size to the disk<br>
utilization within a file system. The two do not directly compare<br>
unless the file system is full and even then it's a crap shoot comparing<br>
the result from "ls -l" to that from "du". There's too many factors and<br>
too many variables that go into it.<br>
<br>
What kind of image is that .fs?<br>
<br>
Is it compressed?<br>
<br>
Is it ext[234]?<br>
<br>
Is it squashfs? In the case of compressed file systems, such as<br>
squashfs, the size of the file system can actually be smaller than the<br>
effective contents, since their space utilization is based on their<br>
uncompressed size (but that's the opposite of what you've got - I'm just<br>
pointing it out to illustrate why the comparison is meaningless).<br>
<br>
Is that .fs image itself a "sparse file" (i.e. not all disk space is<br>
allocated throughout the image, areas that are blocks of 0's may not be<br>
allocated a disk block). An "ls -l" will show you a file "size" but it<br>
may not be the true disk usage of the file if it's sparse.<br>
<br>
What happens when you mounted it over a loop device, enter the mount<br>
point and do a du on it? That would, at least, come closer to a more<br>
valid comparison. How about the results from "df" in that file system?<br>
<br>
Is that file system image intended to contain space for home directories<br>
or var space? If it's intended for heavy weight virtualization, it<br>
probably has considerable empty space for home directories (I usually<br>
allocation 8G-16G for my heavy weight VM images).<br>
<br>
The fact that both the images you show are 2.0G implies, to me, that<br>
they are probably pre-allocated images which are not fully populated and<br>
may even be "sparse files", so "ls -l" is not coming anywhere remotely<br>
NEAR the actual size of the contents and might not even be indicative of<br>
the disk space used in the host file system. Often, an image like that<br>
is created as a fixed size that will contain the largest possible<br>
installation, zeroed out (or left sparse), and a file system build in it<br>
to that fixed size. Then you create your installation in that image and<br>
it may only occupy 10% of the file system. But, you don't care. When<br>
you compress it, the compression utilities are very efficient at<br>
compressing those empty spaces and it costs you very little in your<br>
downloadable size.<br>
<br>
A heavy weight file system image (and this could be an LXC backing store<br>
image as well) generally has to contain space for home and var<br>
directories, it's not just the operating system binaries. An LXC<br>
container, OTOH, back by a directory, is sharing the file system space<br>
with the host OS and doesn't need separately allocated space for home<br>
directories.<br>
<br>
The biggest difference, though, is very likely to be installation<br>
features. The LXC templates create minimal installations. No X, no<br>
GUI, no desktop. Just a bare bones system which you can then flesh out<br>
to what you want. That's by intent. That minimizes the size of the<br>
download images (in the case of the download template), minimizes the<br>
size of the template caches, speeds installation, and allows the freedom<br>
to customize the images without excessive and needless redundancy of<br>
unused packages.<br>
<br>
For heavy weight images running under a hypervisor, these are generally<br>
created from full blown installation images (CDs and DVDs) and contain a<br>
full basic GUI standard installation plus options.<br>
<br>
Compare you're installation packages and see what's installed. Run dpkg<br>
in those file systems and compare what packages you've got installed in<br>
there.<br>
<br>
Installations can easily vary over a couple of orders of magnitude<br>
depending on what you install. I can cram an install of NST (Network<br>
Security Toolkit - a Fedora variation) onto a 650M CD, and that's WITH a<br>
graphical environment. Puppy Linux (Slackware based) still runs in less<br>
than 200M. Without a graphical environment, you could still cram some<br>
slimmed down distro images, like TinyCore (which still chimes in at a<br>
whopping 14M for the slim image!), onto a 50M BBC (Bootable Business<br>
Card - a shaped mini-CD). There are a number of "runlive" images<br>
available for many distributions that will run from a CD (generally from<br>
a squashfs image). OTOH, a full installation of Debian, or Ubuntu, or<br>
Fedora, or CentOS is going to whack out at several gig if not 10's of<br>
gig just for the installation binaries, once their uncompressed.<br>
<br>
Another reason you may not have gotten answers is that few of us would<br>
have any working knowledge of SIMCTL or VNUML. I don't. I had to look<br>
them up. And I'm pretty involved with virtualization on many levels.<br>
There again, you're comparing apples to oranges. This would be like<br>
comparing and LXC container directory to a VMware, VirtualBox, LKVM, or<br>
Xen file system image (all of which I have worked with). The results<br>
would be just as meaningless.<br>
<br>
Even though VNUML looks to be a "user mode linux", it's still running<br>
it's own kernel like a full hypervisor would and would be using file<br>
system images like heavyweight virtualization would. You just can not<br>
compare the size of a file system image to the contents of the file<br>
system in cases like these. That's like asking why a partition is so<br>
much larger that the files it contains (and could even be smaller if it<br>
was a squashfs).<br>
<br>
Honestly, I'm totally unimpressed with the differences in sizes. I just<br>
think the comparison is meaningless without understanding all the<br>
variables that go into it. Even understanding all the variables, the<br>
comparison of file system image size (ls -l) to the utilization of the<br>
file system by its contents (du) is still meaningless. Apples and<br>
oranges. They're both fruit and that's about it.<br>
<br>
> Thank you agin,<br>
<br>
Regards,<br>
Mike<br>
<span class="im HOEnZb">><br>
><br>
> Marcel Sánchez Toledano<br>
><br>
><br>
><br>
><br>
><br>
> 2014-07-17 14:46 GMT+02:00 Marcel Sánchez Toledano<br>
> <<a href="mailto:marcelsanchezt@gmail.com">marcelsanchezt@gmail.com</a>>:<br>
> You mean symbolic links? I don't think so.<br>
><br>
><br>
> Anyway, a du -hs in that folder should return the real size,<br>
> including the sizes of symbolic links original files.<br>
><br>
><br>
><br>
><br>
><br>
> Marcel Sánchez Toledano<br>
><br>
><br>
><br>
><br>
><br>
> 2014-07-17 14:19 GMT+02:00 Oliver Rath <<a href="mailto:rath@mglug.de">rath@mglug.de</a>>:<br>
><br>
> Possybly your lxc installation uses links instead of<br>
> real files?<br>
><br>
> Regards<br>
> Oliver<br>
><br>
><br>
><br>
> On 17.07.2014 14:12, Marcel Sánchez Toledano wrote:<br>
><br>
> > Hi,<br>
> ><br>
> ><br>
> > I'm right now working in a project comparing SIMCTL<br>
> > (VNUML utility, UML) with LxC. In VNUML the aprox.<br>
> > size of virtual machines filesystems located<br>
> > in /usr/share/vnuml/filesystems are 2GB:<br>
> ><br>
> ><br>
> > marcel@ubuntu:/usr/share/vnuml/filesystems$ ls -lh<br>
> ><br>
> > total 4.1G<br>
> > -rw-r--r-- 1 root root 2.0G Oct 9 2013 debian5.fs<br>
> > -rw-r--r-- 1 root root 2.0G Jul 3 07:52 debian6.fs<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > And the size of a LxC rootfs is 246MB:<br>
> ><br>
> ><br>
</span><div class="HOEnZb"><div class="h5">> > Imatge inserida 1<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > How is this possible and which is the explanation of<br>
> > this? The difference of sizes is huge!<br>
> ><br>
> ><br>
> > Thanks,<br>
> ><br>
> ><br>
> > Marcel Sánchez Toledano<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > lxc-users mailing list<br>
> > <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> > <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> lxc-users mailing list<br>
> <a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
> <a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw@WittsEnd.com<br>
/\/\|=mhw=|\/\/ | (678) 463-0932 | <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
NIC whois: MHW9 | An optimist believes we live in the best of all<br>
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!<br>
<br>
</font></span><br>_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br></blockquote></div><br></div>