[lxc-users] About size of images

Marcel Sánchez Toledano marcelsanchezt at gmail.com
Thu Sep 18 10:28:12 UTC 2014


Thank you ver much for this explanation, I really appreciate it!


*Marcel Sánchez Toledano*


2014-08-30 16:25 GMT+02:00 Michael H. Warfield <mhw at wittsend.com>:

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


More information about the lxc-users mailing list