<div dir="ltr"><div class="gmail_default" style="font-size:small">So, if zfs has too high overhead, the ideal backing store should be aufs, btrfs, lvm or overlayfs? My host is Fedora 22, are they all supported?<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 2:03 AM, Fajar A. Nugraha <span dir="ltr"><<a href="mailto:list@fajar.net" target="_blank">list@fajar.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jun 30, 2015 at 7:16 AM, Federico Alves <<a href="mailto:venefax@gmail.com">venefax@gmail.com</a>> wrote:<br>
> I need to create 500 identical containers, but after the first one, I don´t<br>
> want to repeat the same file 500 times. The disk is formatted ext4. What<br>
> should be the best type of format or partition that would be 100% sparse,<br>
> i.e., it would never repeat  the same information.<br>
<br>
</div></div>That's not the definition of sparse: <a href="https://en.wikipedia.org/wiki/Sparse_file" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Sparse_file</a><br>
<br>
If you want to "create a container one time and clone it for the other<br>
499", then you can create container_1 container using<br>
snapshot-cabapble backingstore (e.g. zfs), then run "lxc-clone -s<br>
container_1 container_2". This should create container 2 using<br>
snapshot/clone feature of the storage (at least this works on zfs,<br>
should work on btrfs as well) so that the only additional space that<br>
will be used is only for changed files/blocks (e.g. container config,<br>
/etc/hosts, and so on). Note that as the containers get used, the<br>
changed files will increase (e.g. logs, database files), and those<br>
changed files will use additional space.<br>
<br>
See also "man lxc-clone":<br>
Creates a new container as a clone of an existing container. Two types<br>
of clones are supported: copy and snapshot. A copy clone copies the<br>
root filessytem from the original container to the new. A snapshot<br>
filesystem uses the backing store's snapshot functionality to create a<br>
 very small  copy-on-write snapshot of the original container.<br>
Snapshot clones require the new container backing store to support<br>
snapshotting. Currently this includes only aufs, btrfs, lvm, overlayfs<br>
and zfs. LVM devices do not support snapshots of snapshots.<br>
<br>
<br>
If you REALLY want a system that "would never repeat  the same<br>
information", then you'd need dedup-capable storage. zfs can do that,<br>
but it implies high overhead (e.g. much higher memory requirements<br>
compared to normal, and needs a fast L2ARC), and should NOT be used<br>
unless you REALLY know what you're doing.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Fajar<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" rel="noreferrer" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a></font></span></blockquote></div><br></div>