<div dir="ltr"><br><div>Hello Jose,</div><div><br></div><div>We also have FreeNAS working in our infraestructure, with about 3 TB and ZFS. Some of the pools has compression enabled and you can save space with it. We have this FreeNAS connected to a hypervisor Xen and it works very well and it's stable and sure. We have nine virtual servers some wirtualized and other paravirtualized, and some Windows Server machine all about 2 years in production without any problem. My idea is connect this infrastructure with oVirt wo be able to have some resources for test VMs in that. Only wanted to share as another FreeNas success experience.</div>
<div><br></div><div>Juanjo.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 31, 2013 at 12:33 PM, <span dir="ltr"><<a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif">Thanks a lot Karli, you make my mind clear about deduplication, once again we cannot have the best of both worlds.<br>
<br>I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running on Linux, has no better performance but supports DRDB.<br><br>Jose<br><br><hr><div style="font-size:12pt;font-style:normal;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal">
<div class="im"><b>From: </b>"Karli Sjöberg" <<a href="mailto:Karli.Sjoberg@slu.se" target="_blank">Karli.Sjoberg@slu.se</a>><br><b>To: </b><a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a><br>
<b>Cc: </b>"Jiri Belka" <<a href="mailto:jbelka@redhat.com" target="_blank">jbelka@redhat.com</a>>, <a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a><br></div><b>Sent: </b>Sexta-feira, 31 de Maio de 2013 10:45:41<br>
<b>Subject: </b>Re: [Users] deduplication<div><div class="h5"><br><br>
fre 2013-05-31 klockan 09:50 +0100 skrev <a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a>:
<blockquote><font color="#000000">So, we can say that dedup has more disadvantages than advantages.</font><br>
</blockquote>
<br>
For a primary system; most definitely, yes.<br>
<br>
But for a backup system, that has tons of RAM and SSD's for cache, and you have lots of virtual machines that are based off of the template, or are very much the same, then you have a real use-case. I´m active at the FreeBSD forums where one person reports
storing 150TB of data in only 30TB of physical disk. The best practice of scrubbing is once a week on "enterprise" systems, though he is only able to do it once a month, because that´s how long it takes for a scrub to complete in that system. So you´ve got
to choose performance or savings, you can´t have both.<br>
<br>
<blockquote><br>
<font color="#000000">And what about dedup of Netapp?</font><br>
</blockquote>
<br>
Much better implementation, in my opinion. You are able schedule dedup-runs to go at night so your user´s performance isn´t impacted, and you get the savings. The question is if you value the savings enough to take on price-tag that is NetApp. Or just build
your own FreeBSD/ZFS server with compression enabled and buy in standard HDD's from anywhere... We did;)<br>
<br>
/Karli<br>
<br>
<blockquote><br>
<font color="#000000">Jose</font><br>
<br>
<hr align="center">
</blockquote>
<blockquote><b><font color="#000000">From: </font></b><font color="#000000">"Karli Sjöberg" <<a href="mailto:Karli.Sjoberg@slu.se" target="_blank">Karli.Sjoberg@slu.se</a>></font><br>
<b><font color="#000000">To: </font></b><font color="#000000"><a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a></font><br>
<b><font color="#000000">Cc: </font></b><font color="#000000">"Jiri Belka" <<a href="mailto:jbelka@redhat.com" target="_blank">jbelka@redhat.com</a>>, <a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a></font><br>
<b><font color="#000000">Sent: </font></b><font color="#000000">Quinta-feira, 30 de Maio de 2013 8:33:19</font><br>
<b><font color="#000000">Subject: </font></b><font color="#000000">Re: [Users] deduplication</font><br>
<br>
<font color="#000000">ons 2013-05-29 klockan 09:59 +0100 skrev <a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a>:
</font><br>
<blockquote><font color="#000000">Absolutely agree with you, planning is the best thing to do, but normally people want a plug'n'play system with all included, because there is not much time to think and planning, and there are many companies that know how
to take advantage of this people characteristics.</font><br>
<font color="#000000">Any way, I think another solution for dedup is FreeNAS using ZFS.</font><br>
</blockquote>
<br>
<font color="#000000">FreeNAS is just FreeBSD with a fancy web-ui ontop, so it´s neither more or less of ZFS than you would have otherwise, And regarding dedup in ZFS; Just don´t, it´s not worth it! It´s said that it
</font><font color="#000000"><b>may</b></font><font color="#000000"> increase performance when you have a very suitable usecase, e.g. everything
</font><font color="#000000"><b>exactly</b></font><font color="#000000"> the same over and over. What´s not said is that scrubbing and resilvering slows down to a snail (from hundreds of MB/s, or GB if your system is large enough, down to less than 10), just
from dedup. Also deleting snapshots of datasets that have(or have had) dedup on can kill the entire system, and when I say kill, I mean really fubar. Been there, regretted that... Now, compression on the other hand, you get basically for free and gives decent
savings, I highly recommend that.</font><br>
<br>
<font color="#000000">/Karli</font><br>
<br>
<blockquote><br>
<font color="#000000">Jose</font><br>
<br>
<br>
<hr align="center">
<br>
<b><font color="#000000">From: </font></b><font color="#000000">"Jiri Belka" <<a href="mailto:jbelka@redhat.com" target="_blank">jbelka@redhat.com</a>></font><br>
<b><font color="#000000">To: </font></b><font color="#000000"><a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a></font><br>
<b><font color="#000000">Cc: </font></b><font color="#000000"><a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a></font><br>
<b><font color="#000000">Sent: </font></b><font color="#000000">Quarta-feira, 29 de Maio de 2013 7:33:10</font><br>
<b><font color="#000000">Subject: </font></b><font color="#000000">Re: [Users] deduplication</font><br>
<br>
<font color="#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br>
<font color="#000000"><a href="mailto:suporte@logicworks.pt" target="_blank">suporte@logicworks.pt</a> wrote:</font><br>
<br>
<font color="#000000">> That's why I'm making this questions, to demystify some buzzwords around here.</font><br>
<font color="#000000">> But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them.</font><br>
<font color="#000000">> Share a disk containing "static" data is a good idea, do you know from where I can start?</font><br>
<br>
<font color="#000000">Everything depends on your needs, design planning. Maybe then sharing</font><br>
<font color="#000000">disk would be better to share via NFS/iscsi. Of course if you have many</font><br>
<font color="#000000">VMs each of them is different you will fail. But if you have mostly</font><br>
<font color="#000000">homogeneous environment you can think about this approach. Sure you have</font><br>
<font color="#000000">to have plan for upgrading "base" "static" shared OS data, you have to</font><br>
<font color="#000000">have plan how to install additional software (different destination</font><br>
<font color="#000000">than /usr or /usr/local)... If you already have your own build host</font><br>
<font color="#000000">which builds for you OS packages and you have already your own plan for</font><br>
<font color="#000000">deployment, you have done first steps. If you depend on upgrading each</font><br>
<font color="#000000">machine separately from Internet, then first you should plan your</font><br>
<font color="#000000">environment, configuration management etc.</font><br>
<br>
<font color="#000000">Well, in many times people do not do any planning, they just think some</font><br>
<font color="#000000">good technology would save their "poor" design.</font><br>
<br>
<font color="#000000">j.</font><br>
<br>
<br>
<br>
</blockquote>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: +46-(0)18-67 15 66<br>
<a href="mailto:karli.sjoberg@adm.slu.se" target="_blank">karli.sjoberg@slu.se</a> </td>
</tr>
</tbody>
</table>
</blockquote>
<blockquote><br>
<br>
</blockquote>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: +46-(0)18-67 15 66<br>
<a href="mailto:karli.sjoberg@adm.slu.se" target="_blank">karli.sjoberg@slu.se</a> </td>
</tr>
</tbody>
</table>
</div></div></div><br></div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>