------=_Part_35302_1064706683.1369490560788 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit is deduplication possible? Regards Jose -- Jose Ferradeira http://www.logicworks.pt ------=_Part_35302_1064706683.1369490560788 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: Times New Roman; font-size: 10pt; color: #000000"><div>is deduplication possible?<br></div><div><br></div><div>Regards<br></div><div>Jose<br></div><div><br></div><div>-- <br></div><div><span name="x"></span><hr style="width: 100%; height: 2px;" data-mce-style="width: 100%; height: 2px;">Jose Ferradeira<br>http://www.logicworks.pt<br><span name="x"></span><br></div></div></body></html> ------=_Part_35302_1064706683.1369490560788--
Hi Jose, Deduplication or dedup for short is usually a function of the storage appliance, and as such is a "post-allocation" operation. As a quick example the hypervisor will request the space, allocate all of it, and if space can be reclaimed via a storage side operation like dedup, that's where it's handled. If you're leveraging oVirt with storage appliance that supports dedup it will work just fine with oVirt as well. We DO however support thin provisioning. This is a "pre-allocation" operation handled by oVirt. Instead of just waiting on the storage to reclaim space via a dedup job (if this isn't done inline dedup can be taxing on the storage array and is usually a scheduled job that isn't constant) thin provisioning only allocates the storage space that is actually required. More information can be found on our wiki here: http://www.ovirt.org/Vdsm_Disk_Images Theron Conrey Open Source and Standards, Red Hat @theronconrey ----- Original Message ----- From: suporte@logicworks.pt To: Users@ovirt.org Sent: Saturday, May 25, 2013 9:02:40 AM Subject: [Users] deduplication is deduplication possible? Regards Jose -- Jose Ferradeira http://www.logicworks.pt _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Jose,<br><br>Deduplication or dedup for short is usually a function of =
------=_Part_665_15117543.1369732848335 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Theron,=20 Thanks, that's what I thought. So with dedup we save space in the storage a= nd what about performance, will it increase performance? once it will not u= se the same instance twice, is that right? i.e., if I have 2 VM's (let's sa= y, Fedora 18), with the same kernel, does oVirt run 2 times the 2 instances= or can it manage that so it will not have to run the same software twice, = in order to save resources and performance.=20 I'm not sure if my English is enough for you to realize what I'm trying to = explain.=20 Regards=20 Jose=20 ----- Original Message ----- From: "Theron Conrey" <tconrey@redhat.com>=20 To: suporte@logicworks.pt=20 Cc: Users@ovirt.org=20 Sent: S=C3=A1bado, 25 de Maio de 2013 21:00:39=20 Subject: Re: [Users] deduplication=20 Hi Jose,=20 Deduplication or dedup for short is usually a function of the storage appli= ance, and as such is a "post-allocation" operation. As a quick example the = hypervisor will request the space, allocate all of it, and if space can be = reclaimed via a storage side operation like dedup, that's where it's handle= d.=20 If you're leveraging oVirt with storage appliance that supports dedup it wi= ll work just fine with oVirt as well.=20 We DO however support thin provisioning. This is a "pre-allocation" operati= on handled by oVirt. Instead of just waiting on the storage to reclaim spac= e via a dedup job (if this isn't done inline dedup can be taxing on the sto= rage array and is usually a scheduled job that isn't constant) thin provisi= oning only allocates the storage space that is actually required.=20 More information can be found on our wiki here: http://www.ovirt.org/Vdsm_D= isk_Images=20 Theron Conrey=20 Open Source and Standards, Red Hat=20 @theronconrey=20 ----- Original Message -----=20 From: suporte@logicworks.pt=20 To: Users@ovirt.org=20 Sent: Saturday, May 25, 2013 9:02:40 AM=20 Subject: [Users] deduplication=20 is deduplication possible?=20 Regards=20 Jose=20 --=20 Jose Ferradeira=20 http://www.logicworks.pt=20 _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 ------=_Part_665_15117543.1369732848335 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>Hi Theron,<br><br>Thanks, that's what I thought. So with dedup = we save space in the storage and what about performance, will it increase p= erformance? once it will not use the same instance twice, is that right? i.= e., if I have 2 VM's (let's say, Fedora 18), with the same kernel, does oVi= rt run 2 times the 2 instances or can it manage that so it will not have to= run the same software twice, in order to save resources and performance.<b= r><br>I'm not sure if my English is enough for you to realize what I'm tryi= ng to explain.<br><br>Regards<br>Jose<br><br><hr id=3D"zwchr"><div style=3D= "color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decorat= ion: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>Fr= om: </b>"Theron Conrey" <tconrey@redhat.com><br><b>To: </b>suporte@lo= gicworks.pt<br><b>Cc: </b>Users@ovirt.org<br><b>Sent: </b>S=C3=A1bado, 25 d= e Maio de 2013 21:00:39<br><b>Subject: </b>Re: [Users] deduplication<br><br= the storage appliance, and as such is a "post-allocation" operation. = As a quick example the hypervisor will request the space, allocate all of i= t, and if space can be reclaimed via a storage side operation like dedup, t= hat's where it's handled. <br><br>If you're leveraging oVirt with sto= rage appliance that supports dedup it will work just fine with oVirt as wel= l. <br><br>We DO however support thin provisioning. This is a "= pre-allocation" operation handled by oVirt. Instead of just waiting o= n the storage to reclaim space via a dedup job (if this isn't done inline d= edup can be taxing on the storage array and is usually a scheduled job that= isn't constant) thin provisioning only allocates the storage space that is= actually required. <br><br>More information can be found on our wiki= here: http://www.ovirt.org/Vdsm_Disk_Images<br><br><br>Theron Conrey<br>Op= en Source and Standards, Red Hat<br>@theronconrey<br><br><br><br>----- Orig= inal Message -----<br>From: suporte@logicworks.pt<br>To: Users@ovirt.org<br=
Sent: Saturday, May 25, 2013 9:02:40 AM<br>Subject: [Users] deduplication<= br><br>is deduplication possible? <br><br>Regards <br>Jose <br><br>-- <br><= br>Jose Ferradeira <br>http://www.logicworks.pt <br><br><br>_______________= ________________________________<br>Users mailing list<br>Users@ovirt.org<b= r>http://lists.ovirt.org/mailman/listinfo/users<br></div><br></div></body><= /html> ------=_Part_665_15117543.1369732848335--
On Sat, 25 May 2013 15:02:40 +0100 (WEST) suporte@logicworks.pt wrote:
is deduplication possible?
Regards Jose
If we would talk about OSS systems then Dragon Fly BSD's hammerfs or Open Indiana ZFS (FreeBSD has it too) support deduplication and such filesystems are exported as NFS (so can be used as data domain). j.
On Tue, 28 May 2013 13:00:36 +0200 Jiri Belka <jbelka@redhat.com> wrote:
On Sat, 25 May 2013 15:02:40 +0100 (WEST) suporte@logicworks.pt wrote:
is deduplication possible?
If we would talk about OSS systems then Dragon Fly BSD's hammerfs or Open Indiana ZFS (FreeBSD has it too) support deduplication and such filesystems are exported as NFS (so can be used as data domain).
If you would not use Linux (as they broke having /usr as separate filesystem) and you would design your unix-like VMs correctly, you can share a disk containing "static" data like /usr, /usr/local between VMs as a kind of "deduplication" without being "trapped" by buzzword technologies. j.
------=_Part_1368_23539899.1369747751212 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That's why I'm making this questions, to demystify some buzzwords around he= re.=20 But if you have a strong and good technology why not create buzzwords to ge= t into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wher= e I can start?=20 Thanks=20 Jose=20 ----- Original Message ----- From: "Jiri Belka" <jbelka@redhat.com>=20 To: users@ovirt.org=20 Sent: Ter=C3=A7a-feira, 28 de Maio de 2013 12:05:11=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 13:00:36 +0200=20 Jiri Belka <jbelka@redhat.com> wrote:=20
On Sat, 25 May 2013 15:02:40 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20 =20
is deduplication possible?=20
If we would talk about OSS systems then Dragon Fly BSD's hammerfs or=20 Open Indiana ZFS (FreeBSD has it too) support deduplication and such=20 filesystems are exported as NFS (so can be used as data domain).=20
If you would not use Linux (as they broke having /usr as separate=20 filesystem) and you would design your unix-like VMs correctly, you can=20 share a disk containing "static" data like /usr, /usr/local between=20 VMs as a kind of "deduplication" without being "trapped" by buzzword=20 technologies.=20 j.=20 _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 ------=_Part_1368_23539899.1369747751212 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>That's why I'm making this questions, to demystify some buzzwor= ds around here.<br>But if you have a strong and good technology why not cre= ate buzzwords to get into as many people as possible? without trapped them.= <br>Share a disk containing "static" data is a good idea, do you know from = where I can start?<br><br>Thanks<br>Jose<br><br><hr id=3D"zwchr"><div style= =3D"color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-deco= ration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b=
From: </b>"Jiri Belka" <jbelka@redhat.com><br><b>To: </b>users@ovirt= .org<br><b>Sent: </b>Ter=C3=A7a-feira, 28 de Maio de 2013 12:05:11<br><b>Su= bject: </b>Re: [Users] deduplication<br><br>On Tue, 28 May 2013 13:00:36 +0= 200<br>Jiri Belka <jbelka@redhat.com> wrote:<br><br>> On Sat, 25 M= ay 2013 15:02:40 +0100 (WEST)<br>> suporte@logicworks.pt wrote:<br>> = <br>> > is deduplication possible? <br><br>> If we would talk abou= t OSS systems then Dragon Fly BSD's hammerfs or<br>> Open Indiana ZFS (F= reeBSD has it too) support deduplication and such<br>> filesystems are e= xported as NFS (so can be used as data domain).<br><br>If you would not use= Linux (as they broke having /usr as separate<br>filesystem) and you would = design your unix-like VMs correctly, you can<br>share a disk containing "st= atic" data like /usr, /usr/local between<br>VMs as a kind of "deduplication= " without being "trapped" by buzzword<br>technologies.<br><br>j.<br>_______= ________________________________________<br>Users mailing list<br>Users@ovi= rt.org<br>http://lists.ovirt.org/mailman/listinfo/users<br></div><br></div>= </body></html> ------=_Part_1368_23539899.1369747751212--
On Tue, 28 May 2013 14:29:05 +0100 (WEST) suporte@logicworks.pt wrote:
That's why I'm making this questions, to demystify some buzzwords around here. But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them. Share a disk containing "static" data is a good idea, do you know from where I can start?
Everything depends on your needs, design planning. Maybe then sharing disk would be better to share via NFS/iscsi. Of course if you have many VMs each of them is different you will fail. But if you have mostly homogeneous environment you can think about this approach. Sure you have to have plan for upgrading "base" "static" shared OS data, you have to have plan how to install additional software (different destination than /usr or /usr/local)... If you already have your own build host which builds for you OS packages and you have already your own plan for deployment, you have done first steps. If you depend on upgrading each machine separately from Internet, then first you should plan your environment, configuration management etc. Well, in many times people do not do any planning, they just think some good technology would save their "poor" design. j.
------=_Part_85_9819394.1369817960923 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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. Any way, I think another solution for dedup is FreeNAS using ZFS. Jose ----- Original Message ----- From: "Jiri Belka" <jbelka@redhat.com> To: suporte@logicworks.pt Cc: users@ovirt.org Sent: Quarta-feira, 29 de Maio de 2013 7:33:10 Subject: Re: [Users] deduplication On Tue, 28 May 2013 14:29:05 +0100 (WEST) suporte@logicworks.pt wrote:
That's why I'm making this questions, to demystify some buzzwords around here. But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them. Share a disk containing "static" data is a good idea, do you know from where I can start?
Everything depends on your needs, design planning. Maybe then sharing disk would be better to share via NFS/iscsi. Of course if you have many VMs each of them is different you will fail. But if you have mostly homogeneous environment you can think about this approach. Sure you have to have plan for upgrading "base" "static" shared OS data, you have to have plan how to install additional software (different destination than /usr or /usr/local)... If you already have your own build host which builds for you OS packages and you have already your own plan for deployment, you have done first steps. If you depend on upgrading each machine separately from Internet, then first you should plan your environment, configuration management etc. Well, in many times people do not do any planning, they just think some good technology would save their "poor" design. j. ------=_Part_85_9819394.1369817960923 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>Absolutely agree with you, planning is the best thing to do, bu= t normally people want a plug'n'play system with all included, because ther= e is not much time to think and planning, and there are many companies that= know how to take advantage of this people characteristics.<br>Any way, I t= hink another solution for dedup is FreeNAS using ZFS.<br><br>Jose<br><br><b= r><hr id=3D"zwchr"><div style=3D"color: rgb(0, 0, 0); font-weight: normal; = font-style: normal; text-decoration: none; font-family: Helvetica,Arial,san= s-serif; font-size: 12pt;"><b>From: </b>"Jiri Belka" <jbelka@redhat.com&= gt;<br><b>To: </b>suporte@logicworks.pt<br><b>Cc: </b>users@ovirt.org<br><b=
Sent: </b>Quarta-feira, 29 de Maio de 2013 7:33:10<br><b>Subject: </b>Re: = [Users] deduplication<br><br>On Tue, 28 May 2013 14:29:05 +0100 (WEST)<br>s= uporte@logicworks.pt wrote:<br><br>> That's why I'm making this question= s, to demystify some buzzwords around here. <br>> But if you have a stro= ng and good technology why not create buzzwords to get into as many people = as possible? without trapped them. <br>> Share a disk containing "static= " data is a good idea, do you know from where I can start? <br><br>Everythi= ng depends on your needs, design planning. Maybe then sharing<br>disk would= be better to share via NFS/iscsi. Of course if you have many<br>VMs each o= f them is different you will fail. But if you have mostly<br>homogeneous en= vironment you can think about this approach. Sure you have<br>to have plan = for upgrading "base" "static" shared OS data, you have to<br>have plan how = to install additional software (different destination<br>than /usr or /usr/= local)... If you already have your own build host<br>which builds for you O= S packages and you have already your own plan for<br>deployment, you have d= one first steps. If you depend on upgrading each<br>machine separately from= Internet, then first you should plan your<br>environment, configuration ma= nagement etc.<br><br>Well, in many times people do not do any planning, the= y just think some<br>good technology would save their "poor" design.<br><br= j.<br></div><br></div></body></html> ------=_Part_85_9819394.1369817960923--
--_000_5F9E965F5A80BC468BE5F40576769F092A1CBC51exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b25zIDIwMTMtMDUtMjkga2xvY2thbiAwOTo1OSArMDEwMCBza3JldiBzdXBvcnRlQGxvZ2ljd29y a3MucHQ6DQpBYnNvbHV0ZWx5IGFncmVlIHdpdGggeW91LCBwbGFubmluZyBpcyB0aGUgYmVzdCB0 aGluZyB0byBkbywgYnV0IG5vcm1hbGx5IHBlb3BsZSB3YW50IGEgcGx1ZyduJ3BsYXkgc3lzdGVt IHdpdGggYWxsIGluY2x1ZGVkLCBiZWNhdXNlIHRoZXJlIGlzIG5vdCBtdWNoIHRpbWUgdG8gdGhp bmsgYW5kIHBsYW5uaW5nLCBhbmQgdGhlcmUgYXJlIG1hbnkgY29tcGFuaWVzIHRoYXQga25vdyBo b3cgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBwZW9wbGUgY2hhcmFjdGVyaXN0aWNzLg0KQW55 IHdheSwgSSB0aGluayBhbm90aGVyIHNvbHV0aW9uIGZvciBkZWR1cCBpcyBGcmVlTkFTIHVzaW5n IFpGUy4NCg0KRnJlZU5BUyBpcyBqdXN0IEZyZWVCU0Qgd2l0aCBhIGZhbmN5IHdlYi11aSBvbnRv cCwgc28gaXTCtHMgbmVpdGhlciBtb3JlIG9yIGxlc3Mgb2YgWkZTIHRoYW4geW91IHdvdWxkIGhh dmUgb3RoZXJ3aXNlLCBBbmQgcmVnYXJkaW5nIGRlZHVwIGluIFpGUzsgSnVzdCBkb27CtHQsIGl0 wrRzIG5vdCB3b3J0aCBpdCEgSXTCtHMgc2FpZCB0aGF0IGl0IG1heSBpbmNyZWFzZSBwZXJmb3Jt YW5jZSB3aGVuIHlvdSBoYXZlIGEgdmVyeSBzdWl0YWJsZSB1c2VjYXNlLCBlLmcuIGV2ZXJ5dGhp bmcgZXhhY3RseSB0aGUgc2FtZSBvdmVyIGFuZCBvdmVyLiBXaGF0wrRzIG5vdCBzYWlkIGlzIHRo YXQgc2NydWJiaW5nIGFuZCByZXNpbHZlcmluZyBzbG93cyBkb3duIHRvIGEgc25haWwgKGZyb20g aHVuZHJlZHMgb2YgTUIvcywgb3IgR0IgaWYgeW91ciBzeXN0ZW0gaXMgbGFyZ2UgZW5vdWdoLCBk b3duIHRvIGxlc3MgdGhhbiAxMCksIGp1c3QgZnJvbSBkZWR1cC4gQWxzbyBkZWxldGluZyBzbmFw c2hvdHMgb2YgZGF0YXNldHMgdGhhdCBoYXZlKG9yIGhhdmUgaGFkKSBkZWR1cCBvbiBjYW4ga2ls bCB0aGUgZW50aXJlIHN5c3RlbSwgYW5kIHdoZW4gSSBzYXkga2lsbCwgSSBtZWFuIHJlYWxseSBm dWJhci4gQmVlbiB0aGVyZSwgcmVncmV0dGVkIHRoYXQuLi4gTm93LCBjb21wcmVzc2lvbiBvbiB0 aGUgb3RoZXIgaGFuZCwgeW91IGdldCBiYXNpY2FsbHkgZm9yIGZyZWUgYW5kIGdpdmVzIGRlY2Vu dCBzYXZpbmdzLCBJIGhpZ2hseSByZWNvbW1lbmQgdGhhdC4NCg0KL0thcmxpDQoNCg0KSm9zZQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiAiSmlyaSBCZWxrYSIg PGpiZWxrYUByZWRoYXQuY29tPg0KVG86IHN1cG9ydGVAbG9naWN3b3Jrcy5wdA0KQ2M6IHVzZXJz QG92aXJ0Lm9yZw0KU2VudDogUXVhcnRhLWZlaXJhLCAyOSBkZSBNYWlvIGRlIDIwMTMgNzozMzox MA0KU3ViamVjdDogUmU6IFtVc2Vyc10gZGVkdXBsaWNhdGlvbg0KDQpPbiBUdWUsIDI4IE1heSAy MDEzIDE0OjI5OjA1ICswMTAwIChXRVNUKQ0Kc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0IHdyb3RlOg0K DQo+IFRoYXQncyB3aHkgSSdtIG1ha2luZyB0aGlzIHF1ZXN0aW9ucywgdG8gZGVteXN0aWZ5IHNv bWUgYnV6endvcmRzIGFyb3VuZCBoZXJlLg0KPiBCdXQgaWYgeW91IGhhdmUgYSBzdHJvbmcgYW5k IGdvb2QgdGVjaG5vbG9neSB3aHkgbm90IGNyZWF0ZSBidXp6d29yZHMgdG8gZ2V0IGludG8gYXMg bWFueSBwZW9wbGUgYXMgcG9zc2libGU/IHdpdGhvdXQgdHJhcHBlZCB0aGVtLg0KPiBTaGFyZSBh IGRpc2sgY29udGFpbmluZyAic3RhdGljIiBkYXRhIGlzIGEgZ29vZCBpZGVhLCBkbyB5b3Uga25v dyBmcm9tIHdoZXJlIEkgY2FuIHN0YXJ0Pw0KDQpFdmVyeXRoaW5nIGRlcGVuZHMgb24geW91ciBu ZWVkcywgZGVzaWduIHBsYW5uaW5nLiBNYXliZSB0aGVuIHNoYXJpbmcNCmRpc2sgd291bGQgYmUg YmV0dGVyIHRvIHNoYXJlIHZpYSBORlMvaXNjc2kuIE9mIGNvdXJzZSBpZiB5b3UgaGF2ZSBtYW55 DQpWTXMgZWFjaCBvZiB0aGVtIGlzIGRpZmZlcmVudCB5b3Ugd2lsbCBmYWlsLiBCdXQgaWYgeW91 IGhhdmUgbW9zdGx5DQpob21vZ2VuZW91cyBlbnZpcm9ubWVudCB5b3UgY2FuIHRoaW5rIGFib3V0 IHRoaXMgYXBwcm9hY2guIFN1cmUgeW91IGhhdmUNCnRvIGhhdmUgcGxhbiBmb3IgdXBncmFkaW5n ICJiYXNlIiAic3RhdGljIiBzaGFyZWQgT1MgZGF0YSwgeW91IGhhdmUgdG8NCmhhdmUgcGxhbiBo b3cgdG8gaW5zdGFsbCBhZGRpdGlvbmFsIHNvZnR3YXJlIChkaWZmZXJlbnQgZGVzdGluYXRpb24N CnRoYW4gL3VzciBvciAvdXNyL2xvY2FsKS4uLiBJZiB5b3UgYWxyZWFkeSBoYXZlIHlvdXIgb3du IGJ1aWxkIGhvc3QNCndoaWNoIGJ1aWxkcyBmb3IgeW91IE9TIHBhY2thZ2VzIGFuZCB5b3UgaGF2 ZSBhbHJlYWR5IHlvdXIgb3duIHBsYW4gZm9yDQpkZXBsb3ltZW50LCB5b3UgaGF2ZSBkb25lIGZp cnN0IHN0ZXBzLiBJZiB5b3UgZGVwZW5kIG9uIHVwZ3JhZGluZyBlYWNoDQptYWNoaW5lIHNlcGFy YXRlbHkgZnJvbSBJbnRlcm5ldCwgdGhlbiBmaXJzdCB5b3Ugc2hvdWxkIHBsYW4geW91cg0KZW52 aXJvbm1lbnQsIGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBldGMuDQoNCldlbGwsIGluIG1hbnkg dGltZXMgcGVvcGxlIGRvIG5vdCBkbyBhbnkgcGxhbm5pbmcsIHRoZXkganVzdCB0aGluayBzb21l DQpnb29kIHRlY2hub2xvZ3kgd291bGQgc2F2ZSB0aGVpciAicG9vciIgZGVzaWduLg0KDQpqLg0K DQoNCg0KDQotLQ0KDQpNZWQgVsOkbmxpZ2EgSMOkbHNuaW5nYXINCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkthcmxpIFNqw7ZiZXJnDQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFs IFNjaWVuY2VzDQpCb3ggNzA3OSAoVmlzaXRpbmcgQWRkcmVzcyBLcm9uw6VzdsOkZ2VuIDgpDQpT LTc1MCAwNyBVcHBzYWxhLCBTd2VkZW4NClBob25lOiAgKzQ2LSgwKTE4LTY3IDE1IDY2DQprYXJs aS5zam9iZXJnQHNsdS5zZTxtYWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlPg0K --_000_5F9E965F5A80BC468BE5F40576769F092A1CBC51exchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpvbnMgMjAxMy0wNS0y OSBrbG9ja2FuIDA5OjU5ICYjNDM7MDEwMCBza3JldiBzdXBvcnRlQGxvZ2ljd29ya3MucHQ6DQo8 YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+QWJzb2x1dGVseSBh Z3JlZSB3aXRoIHlvdSwgcGxhbm5pbmcgaXMgdGhlIGJlc3QgdGhpbmcgdG8gZG8sIGJ1dCBub3Jt YWxseSBwZW9wbGUgd2FudCBhIHBsdWcnbidwbGF5IHN5c3RlbSB3aXRoIGFsbCBpbmNsdWRlZCwg YmVjYXVzZSB0aGVyZSBpcyBub3QgbXVjaCB0aW1lIHRvIHRoaW5rIGFuZCBwbGFubmluZywgYW5k IHRoZXJlIGFyZSBtYW55IGNvbXBhbmllcyB0aGF0DQoga25vdyBob3cgdG8gdGFrZSBhZHZhbnRh Z2Ugb2YgdGhpcyBwZW9wbGUgY2hhcmFjdGVyaXN0aWNzLjwvZm9udD48YnI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+QW55IHdheSwgSSB0aGluayBhbm90aGVyIHNvbHV0aW9uIGZvciBkZWR1cCBp cyBGcmVlTkFTIHVzaW5nIFpGUy48L2ZvbnQ+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KRnJl ZU5BUyBpcyBqdXN0IEZyZWVCU0Qgd2l0aCBhIGZhbmN5IHdlYi11aSBvbnRvcCwgc28gaXTCtHMg bmVpdGhlciBtb3JlIG9yIGxlc3Mgb2YgWkZTIHRoYW4geW91IHdvdWxkIGhhdmUgb3RoZXJ3aXNl LCBBbmQgcmVnYXJkaW5nIGRlZHVwIGluIFpGUzsgSnVzdCBkb27CtHQsIGl0wrRzIG5vdCB3b3J0 aCBpdCEgSXTCtHMgc2FpZCB0aGF0IGl0DQo8Yj5tYXk8L2I+IGluY3JlYXNlIHBlcmZvcm1hbmNl IHdoZW4geW91IGhhdmUgYSB2ZXJ5IHN1aXRhYmxlIHVzZWNhc2UsIGUuZy4gZXZlcnl0aGluZw0K PGI+ZXhhY3RseTwvYj4gdGhlIHNhbWUgb3ZlciBhbmQgb3Zlci4gV2hhdMK0cyBub3Qgc2FpZCBp cyB0aGF0IHNjcnViYmluZyBhbmQgcmVzaWx2ZXJpbmcgc2xvd3MgZG93biB0byBhIHNuYWlsIChm cm9tIGh1bmRyZWRzIG9mIE1CL3MsIG9yIEdCIGlmIHlvdXIgc3lzdGVtIGlzIGxhcmdlIGVub3Vn aCwgZG93biB0byBsZXNzIHRoYW4gMTApLCBqdXN0IGZyb20gZGVkdXAuIEFsc28gZGVsZXRpbmcg c25hcHNob3RzIG9mIGRhdGFzZXRzIHRoYXQgaGF2ZShvcg0KIGhhdmUgaGFkKSBkZWR1cCBvbiBj YW4ga2lsbCB0aGUgZW50aXJlIHN5c3RlbSwgYW5kIHdoZW4gSSBzYXkga2lsbCwgSSBtZWFuIHJl YWxseSBmdWJhci4gQmVlbiB0aGVyZSwgcmVncmV0dGVkIHRoYXQuLi4gTm93LCBjb21wcmVzc2lv biBvbiB0aGUgb3RoZXIgaGFuZCwgeW91IGdldCBiYXNpY2FsbHkgZm9yIGZyZWUgYW5kIGdpdmVz IGRlY2VudCBzYXZpbmdzLCBJIGhpZ2hseSByZWNvbW1lbmQgdGhhdC48YnI+DQo8YnI+DQovS2Fy bGk8YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48YnI+DQo8Zm9udCBjb2xvcj0i IzAwMDAwMCI+Sm9zZTwvZm9udD48YnI+DQo8YnI+DQo8YnI+DQo8aHIgYWxpZ249ImNlbnRlciI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48Yj48Zm9udCBjb2xvcj0i IzAwMDAwMCI+RnJvbTogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+JnF1b3Q7Smly aSBCZWxrYSZxdW90OyAmbHQ7amJlbGthQHJlZGhhdC5jb20mZ3Q7PC9mb250Pjxicj4NCjxiPjxm b250IGNvbG9yPSIjMDAwMDAwIj5UbzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAw Ij5DYzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+dXNlcnNAb3ZpcnQub3JnPC9m b250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5TZW50OiA8L2ZvbnQ+PC9iPjxmb250 IGNvbG9yPSIjMDAwMDAwIj5RdWFydGEtZmVpcmEsIDI5IGRlIE1haW8gZGUgMjAxMyA3OjMzOjEw PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5TdWJqZWN0OiA8L2ZvbnQ+PC9i Pjxmb250IGNvbG9yPSIjMDAwMDAwIj5SZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uPC9mb250Pjxi cj4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5PbiBUdWUsIDI4IE1heSAyMDEzIDE0OjI5 OjA1ICYjNDM7MDEwMCAoV0VTVCk8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPnN1 cG9ydGVAbG9naWN3b3Jrcy5wdCB3cm90ZTo8L2ZvbnQ+PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9 IiMwMDAwMDAiPiZndDsgVGhhdCdzIHdoeSBJJ20gbWFraW5nIHRoaXMgcXVlc3Rpb25zLCB0byBk ZW15c3RpZnkgc29tZSBidXp6d29yZHMgYXJvdW5kIGhlcmUuDQo8L2ZvbnQ+PGJyPg0KPGZvbnQg Y29sb3I9IiMwMDAwMDAiPiZndDsgQnV0IGlmIHlvdSBoYXZlIGEgc3Ryb25nIGFuZCBnb29kIHRl Y2hub2xvZ3kgd2h5IG5vdCBjcmVhdGUgYnV6endvcmRzIHRvIGdldCBpbnRvIGFzIG1hbnkgcGVv cGxlIGFzIHBvc3NpYmxlPyB3aXRob3V0IHRyYXBwZWQgdGhlbS4NCjwvZm9udD48YnI+DQo8Zm9u dCBjb2xvcj0iIzAwMDAwMCI+Jmd0OyBTaGFyZSBhIGRpc2sgY29udGFpbmluZyAmcXVvdDtzdGF0 aWMmcXVvdDsgZGF0YSBpcyBhIGdvb2QgaWRlYSwgZG8geW91IGtub3cgZnJvbSB3aGVyZSBJIGNh biBzdGFydD8NCjwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+RXZlcnl0 aGluZyBkZXBlbmRzIG9uIHlvdXIgbmVlZHMsIGRlc2lnbiBwbGFubmluZy4gTWF5YmUgdGhlbiBz aGFyaW5nPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5kaXNrIHdvdWxkIGJlIGJl dHRlciB0byBzaGFyZSB2aWEgTkZTL2lzY3NpLiBPZiBjb3Vyc2UgaWYgeW91IGhhdmUgbWFueTwv Zm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Vk1zIGVhY2ggb2YgdGhlbSBpcyBkaWZm ZXJlbnQgeW91IHdpbGwgZmFpbC4gQnV0IGlmIHlvdSBoYXZlIG1vc3RseTwvZm9udD48YnI+DQo8 Zm9udCBjb2xvcj0iIzAwMDAwMCI+aG9tb2dlbmVvdXMgZW52aXJvbm1lbnQgeW91IGNhbiB0aGlu ayBhYm91dCB0aGlzIGFwcHJvYWNoLiBTdXJlIHlvdSBoYXZlPC9mb250Pjxicj4NCjxmb250IGNv bG9yPSIjMDAwMDAwIj50byBoYXZlIHBsYW4gZm9yIHVwZ3JhZGluZyAmcXVvdDtiYXNlJnF1b3Q7 ICZxdW90O3N0YXRpYyZxdW90OyBzaGFyZWQgT1MgZGF0YSwgeW91IGhhdmUgdG88L2ZvbnQ+PGJy Pg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPmhhdmUgcGxhbiBob3cgdG8gaW5zdGFsbCBhZGRpdGlv bmFsIHNvZnR3YXJlIChkaWZmZXJlbnQgZGVzdGluYXRpb248L2ZvbnQ+PGJyPg0KPGZvbnQgY29s b3I9IiMwMDAwMDAiPnRoYW4gL3VzciBvciAvdXNyL2xvY2FsKS4uLiBJZiB5b3UgYWxyZWFkeSBo YXZlIHlvdXIgb3duIGJ1aWxkIGhvc3Q8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAi PndoaWNoIGJ1aWxkcyBmb3IgeW91IE9TIHBhY2thZ2VzIGFuZCB5b3UgaGF2ZSBhbHJlYWR5IHlv dXIgb3duIHBsYW4gZm9yPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5kZXBsb3lt ZW50LCB5b3UgaGF2ZSBkb25lIGZpcnN0IHN0ZXBzLiBJZiB5b3UgZGVwZW5kIG9uIHVwZ3JhZGlu ZyBlYWNoPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5tYWNoaW5lIHNlcGFyYXRl bHkgZnJvbSBJbnRlcm5ldCwgdGhlbiBmaXJzdCB5b3Ugc2hvdWxkIHBsYW4geW91cjwvZm9udD48 YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+ZW52aXJvbm1lbnQsIGNvbmZpZ3VyYXRpb24gbWFu YWdlbWVudCBldGMuPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5XZWxs LCBpbiBtYW55IHRpbWVzIHBlb3BsZSBkbyBub3QgZG8gYW55IHBsYW5uaW5nLCB0aGV5IGp1c3Qg dGhpbmsgc29tZTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Z29vZCB0ZWNobm9s b2d5IHdvdWxkIHNhdmUgdGhlaXIgJnF1b3Q7cG9vciZxdW90OyBkZXNpZ24uPC9mb250Pjxicj4N Cjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5qLjwvZm9udD48YnI+DQo8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnI+DQo8dGFibGUgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAw JSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQ+LS0gPGJyPg0KPGJyPg0KTWVkIFbDpG5saWdhIEjDpGxz bmluZ2FyPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkthcmxpIFNqw7ZiZXJnPGJy Pg0KU3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlczxicj4NCkJveCA3 MDc5IChWaXNpdGluZyBBZGRyZXNzIEtyb27DpXN2w6RnZW4gOCk8YnI+DQpTLTc1MCAwNyBVcHBz YWxhLCBTd2VkZW48YnI+DQpQaG9uZTogJm5ic3A7JiM0Mzs0Ni0oMCkxOC02NyAxNSA2Njxicj4N CjxhIGhyZWY9Im1haWx0bzprYXJsaS5zam9iZXJnQGFkbS5zbHUuc2UiPmthcmxpLnNqb2JlcmdA c2x1LnNlPC9hPiA8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5F9E965F5A80BC468BE5F40576769F092A1CBC51exchange21_--
------=_Part_850_29656067.1369990209067 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, we can say that dedup has more disadvantages than advantages.=20 And what about dedup of Netapp?=20 Jose=20 ----- Original Message ----- From: "Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se>=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" <jbelka@redhat.com>, users@ovirt.org=20 Sent: Quinta-feira, 30 de Maio de 2013 8:33:19=20 Subject: Re: [Users] deduplication=20 ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt:=20 Absolutely agree with you, planning is the best thing to do, but normally p= eople want a plug'n'play system with all included, because there is not muc= h time to think and planning, and there are many companies that know how to= take advantage of this people characteristics.=20 Any way, I think another solution for dedup is FreeNAS using ZFS.=20 FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it may increa= se performance when you have a very suitable usecase, e.g. everything exact= ly the same over and over. What=C2=B4s not said is that scrubbing and resil= vering slows down to a snail (from hundreds of MB/s, or GB if your system i= s large enough, down to less than 10), just from dedup. Also deleting snaps= hots 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... N= ow, compression on the other hand, you get basically for free and gives dec= ent savings, I highly recommend that.=20 /Karli=20 <blockquote> Jose=20 </blockquote> <blockquote> From: "Jiri Belka" <jbelka@redhat.com>=20 To: suporte@logicworks.pt=20 Cc: users@ovirt.org=20 Sent: Quarta-feira, 29 de Maio de 2013 7:33:10=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 14:29:05 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20
That's why I'm making this questions, to demystify some buzzwords around = here.=20 But if you have a strong and good technology why not create buzzwords to = get into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wh= ere I can start?=20
Everything depends on your needs, design planning. Maybe then sharing=20 disk would be better to share via NFS/iscsi. Of course if you have many=20 VMs each of them is different you will fail. But if you have mostly=20 homogeneous environment you can think about this approach. Sure you have=20 to have plan for upgrading "base" "static" shared OS data, you have to=20 have plan how to install additional software (different destination=20 than /usr or /usr/local)... If you already have your own build host=20 which builds for you OS packages and you have already your own plan for=20 deployment, you have done first steps. If you depend on upgrading each=20 machine separately from Internet, then first you should plan your=20 environment, configuration management etc.=20 Well, in many times people do not do any planning, they just think some=20 good technology would save their "poor" design.=20 j.=20 </blockquote> <blockquote> </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 ------=_Part_850_29656067.1369990209067 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>So, we can say that dedup has more disadvantages than advantage= s.<br><br>And what about dedup of Netapp?<br><br>Jose<br><br><hr id=3D"zwch= r"><div style=3D"color: rgb(0, 0, 0); font-weight: normal; font-style: norm= al; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-si= ze: 12pt;"><b>From: </b>"Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se><b= r><b>To: </b>suporte@logicworks.pt<br><b>Cc: </b>"Jiri Belka" <jbelka@re= dhat.com>, users@ovirt.org<br><b>Sent: </b>Quinta-feira, 30 de Maio de 2= 013 8:33:19<br><b>Subject: </b>Re: [Users] deduplication<br><br> ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt: <blockquote><font color=3D"#000000">Absolutely agree with you, planning is = the best thing to do, but normally people want a plug'n'play system with al= l 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=3D"#000000">Any way, I think another solution for dedup is Free= NAS using ZFS.</font><br> </blockquote> <br> FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it <b>may</b> increase performance when you have a very suitable usecase, e.g.= everything <b>exactly</b> the same over and over. What=C2=B4s not said is that scrubbi= ng and resilvering slows down to a snail (from hundreds of MB/s, or GB if y= our system is large enough, down to less than 10), just from dedup. Also de= leting 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 recomme= nd that.<br> <br> /Karli<br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <br> <hr align=3D"center"> </blockquote> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Jiri Belka" <jbelka@redhat.com></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000">suporte@l= ogicworks.pt</font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">users@ovi= rt.org</font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quarta-= feira, 29 de Maio de 2013 7:33:10</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br=
<font color=3D"#000000">suporte@logicworks.pt wrote:</font><br> <br> <font color=3D"#000000">> That's why I'm making this questions, to demys= tify some buzzwords around here. </font><br> <font color=3D"#000000">> But if you have a strong and good technology w= hy not create buzzwords to get into as many people as possible? without tra= pped them. </font><br> <font color=3D"#000000">> Share a disk containing "static" data is a goo= d idea, do you know from where I can start? </font><br> <br> <font color=3D"#000000">Everything depends on your needs, design planning. = Maybe then sharing</font><br> <font color=3D"#000000">disk would be better to share via NFS/iscsi. Of cou= rse if you have many</font><br> <font color=3D"#000000">VMs each of them is different you will fail. But if= you have mostly</font><br> <font color=3D"#000000">homogeneous environment you can think about this ap= proach. Sure you have</font><br> <font color=3D"#000000">to have plan for upgrading "base" "static" shared O= S data, you have to</font><br> <font color=3D"#000000">have plan how to install additional software (diffe= rent destination</font><br> <font color=3D"#000000">than /usr or /usr/local)... If you already have you= r own build host</font><br> <font color=3D"#000000">which builds for you OS packages and you have alrea= dy your own plan for</font><br> <font color=3D"#000000">deployment, you have done first steps. If you depen= d on upgrading each</font><br> <font color=3D"#000000">machine separately from Internet, then first you sh= ould plan your</font><br> <font color=3D"#000000">environment, configuration management etc.</font><b= r> <br> <font color=3D"#000000">Well, in many times people do not do any planning, = they just think some</font><br> <font color=3D"#000000">good technology would save their "poor" design.</fo= nt><br> <br> <font color=3D"#000000">j.</font><br> <br> </blockquote> <blockquote><br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </div><br></div></body></html> ------=_Part_850_29656067.1369990209067--
--_000_5F9E965F5A80BC468BE5F40576769F092A1CD2EDexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZnJlIDIwMTMtMDUtMzEga2xvY2thbiAwOTo1MCArMDEwMCBza3JldiBzdXBvcnRlQGxvZ2ljd29y a3MucHQ6DQpTbywgd2UgY2FuIHNheSB0aGF0IGRlZHVwIGhhcyBtb3JlIGRpc2FkdmFudGFnZXMg dGhhbiBhZHZhbnRhZ2VzLg0KDQpGb3IgYSBwcmltYXJ5IHN5c3RlbTsgbW9zdCBkZWZpbml0ZWx5 LCB5ZXMuDQoNCkJ1dCBmb3IgYSBiYWNrdXAgc3lzdGVtLCB0aGF0IGhhcyB0b25zIG9mIFJBTSBh bmQgU1NEJ3MgZm9yIGNhY2hlLCBhbmQgeW91IGhhdmUgbG90cyBvZiB2aXJ0dWFsIG1hY2hpbmVz IHRoYXQgYXJlIGJhc2VkIG9mZiBvZiB0aGUgdGVtcGxhdGUsIG9yIGFyZSB2ZXJ5IG11Y2ggdGhl IHNhbWUsIHRoZW4geW91IGhhdmUgYSByZWFsIHVzZS1jYXNlLiBJwrRtIGFjdGl2ZSBhdCB0aGUg RnJlZUJTRCBmb3J1bXMgd2hlcmUgb25lIHBlcnNvbiByZXBvcnRzIHN0b3JpbmcgMTUwVEIgb2Yg ZGF0YSBpbiBvbmx5IDMwVEIgb2YgcGh5c2ljYWwgZGlzay4gVGhlIGJlc3QgcHJhY3RpY2Ugb2Yg c2NydWJiaW5nIGlzIG9uY2UgYSB3ZWVrIG9uICJlbnRlcnByaXNlIiBzeXN0ZW1zLCB0aG91Z2gg aGUgaXMgb25seSBhYmxlIHRvIGRvIGl0IG9uY2UgYSBtb250aCwgYmVjYXVzZSB0aGF0wrRzIGhv dyBsb25nIGl0IHRha2VzIGZvciBhIHNjcnViIHRvIGNvbXBsZXRlIGluIHRoYXQgc3lzdGVtLiBT byB5b3XCtHZlIGdvdCB0byBjaG9vc2UgcGVyZm9ybWFuY2Ugb3Igc2F2aW5ncywgeW91IGNhbsK0 dCBoYXZlIGJvdGguDQoNCg0KQW5kIHdoYXQgYWJvdXQgZGVkdXAgb2YgTmV0YXBwPw0KDQpNdWNo IGJldHRlciBpbXBsZW1lbnRhdGlvbiwgaW4gbXkgb3Bpbmlvbi4gWW91IGFyZSBhYmxlIHNjaGVk dWxlIGRlZHVwLXJ1bnMgdG8gZ28gYXQgbmlnaHQgc28geW91ciB1c2VywrRzIHBlcmZvcm1hbmNl IGlzbsK0dCBpbXBhY3RlZCwgYW5kIHlvdSBnZXQgdGhlIHNhdmluZ3MuIFRoZSBxdWVzdGlvbiBp cyBpZiB5b3UgdmFsdWUgdGhlIHNhdmluZ3MgZW5vdWdoIHRvIHRha2Ugb24gcHJpY2UtdGFnIHRo YXQgaXMgTmV0QXBwLiBPciBqdXN0IGJ1aWxkIHlvdXIgb3duIEZyZWVCU0QvWkZTIHNlcnZlciB3 aXRoIGNvbXByZXNzaW9uIGVuYWJsZWQgYW5kIGJ1eSBpbiBzdGFuZGFyZCBIREQncyBmcm9tIGFu eXdoZXJlLi4uIFdlIGRpZDspDQoNCi9LYXJsaQ0KDQoNCkpvc2UNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206ICJLYXJsaSBTasO2YmVyZyIgPEthcmxpLlNqb2JlcmdA c2x1LnNlPg0KVG86IHN1cG9ydGVAbG9naWN3b3Jrcy5wdA0KQ2M6ICJKaXJpIEJlbGthIiA8amJl bGthQHJlZGhhdC5jb20+LCB1c2Vyc0BvdmlydC5vcmcNClNlbnQ6IFF1aW50YS1mZWlyYSwgMzAg ZGUgTWFpbyBkZSAyMDEzIDg6MzM6MTkNClN1YmplY3Q6IFJlOiBbVXNlcnNdIGRlZHVwbGljYXRp b24NCg0Kb25zIDIwMTMtMDUtMjkga2xvY2thbiAwOTo1OSArMDEwMCBza3JldiBzdXBvcnRlQGxv Z2ljd29ya3MucHQ6DQpBYnNvbHV0ZWx5IGFncmVlIHdpdGggeW91LCBwbGFubmluZyBpcyB0aGUg YmVzdCB0aGluZyB0byBkbywgYnV0IG5vcm1hbGx5IHBlb3BsZSB3YW50IGEgcGx1ZyduJ3BsYXkg c3lzdGVtIHdpdGggYWxsIGluY2x1ZGVkLCBiZWNhdXNlIHRoZXJlIGlzIG5vdCBtdWNoIHRpbWUg dG8gdGhpbmsgYW5kIHBsYW5uaW5nLCBhbmQgdGhlcmUgYXJlIG1hbnkgY29tcGFuaWVzIHRoYXQg a25vdyBob3cgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBwZW9wbGUgY2hhcmFjdGVyaXN0aWNz Lg0KQW55IHdheSwgSSB0aGluayBhbm90aGVyIHNvbHV0aW9uIGZvciBkZWR1cCBpcyBGcmVlTkFT IHVzaW5nIFpGUy4NCg0KRnJlZU5BUyBpcyBqdXN0IEZyZWVCU0Qgd2l0aCBhIGZhbmN5IHdlYi11 aSBvbnRvcCwgc28gaXTCtHMgbmVpdGhlciBtb3JlIG9yIGxlc3Mgb2YgWkZTIHRoYW4geW91IHdv dWxkIGhhdmUgb3RoZXJ3aXNlLCBBbmQgcmVnYXJkaW5nIGRlZHVwIGluIFpGUzsgSnVzdCBkb27C tHQsIGl0wrRzIG5vdCB3b3J0aCBpdCEgSXTCtHMgc2FpZCB0aGF0IGl0IG1heSBpbmNyZWFzZSBw ZXJmb3JtYW5jZSB3aGVuIHlvdSBoYXZlIGEgdmVyeSBzdWl0YWJsZSB1c2VjYXNlLCBlLmcuIGV2 ZXJ5dGhpbmcgZXhhY3RseSB0aGUgc2FtZSBvdmVyIGFuZCBvdmVyLiBXaGF0wrRzIG5vdCBzYWlk IGlzIHRoYXQgc2NydWJiaW5nIGFuZCByZXNpbHZlcmluZyBzbG93cyBkb3duIHRvIGEgc25haWwg KGZyb20gaHVuZHJlZHMgb2YgTUIvcywgb3IgR0IgaWYgeW91ciBzeXN0ZW0gaXMgbGFyZ2UgZW5v dWdoLCBkb3duIHRvIGxlc3MgdGhhbiAxMCksIGp1c3QgZnJvbSBkZWR1cC4gQWxzbyBkZWxldGlu ZyBzbmFwc2hvdHMgb2YgZGF0YXNldHMgdGhhdCBoYXZlKG9yIGhhdmUgaGFkKSBkZWR1cCBvbiBj YW4ga2lsbCB0aGUgZW50aXJlIHN5c3RlbSwgYW5kIHdoZW4gSSBzYXkga2lsbCwgSSBtZWFuIHJl YWxseSBmdWJhci4gQmVlbiB0aGVyZSwgcmVncmV0dGVkIHRoYXQuLi4gTm93LCBjb21wcmVzc2lv biBvbiB0aGUgb3RoZXIgaGFuZCwgeW91IGdldCBiYXNpY2FsbHkgZm9yIGZyZWUgYW5kIGdpdmVz IGRlY2VudCBzYXZpbmdzLCBJIGhpZ2hseSByZWNvbW1lbmQgdGhhdC4NCg0KL0thcmxpDQoNCg0K Sm9zZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206ICJKaXJp IEJlbGthIiA8amJlbGthQHJlZGhhdC5jb20+DQpUbzogc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0DQpD YzogdXNlcnNAb3ZpcnQub3JnDQpTZW50OiBRdWFydGEtZmVpcmEsIDI5IGRlIE1haW8gZGUgMjAx MyA3OjMzOjEwDQpTdWJqZWN0OiBSZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uDQoNCk9uIFR1ZSwg MjggTWF5IDIwMTMgMTQ6Mjk6MDUgKzAxMDAgKFdFU1QpDQpzdXBvcnRlQGxvZ2ljd29ya3MucHQg d3JvdGU6DQoNCj4gVGhhdCdzIHdoeSBJJ20gbWFraW5nIHRoaXMgcXVlc3Rpb25zLCB0byBkZW15 c3RpZnkgc29tZSBidXp6d29yZHMgYXJvdW5kIGhlcmUuDQo+IEJ1dCBpZiB5b3UgaGF2ZSBhIHN0 cm9uZyBhbmQgZ29vZCB0ZWNobm9sb2d5IHdoeSBub3QgY3JlYXRlIGJ1enp3b3JkcyB0byBnZXQg aW50byBhcyBtYW55IHBlb3BsZSBhcyBwb3NzaWJsZT8gd2l0aG91dCB0cmFwcGVkIHRoZW0uDQo+ IFNoYXJlIGEgZGlzayBjb250YWluaW5nICJzdGF0aWMiIGRhdGEgaXMgYSBnb29kIGlkZWEsIGRv IHlvdSBrbm93IGZyb20gd2hlcmUgSSBjYW4gc3RhcnQ/DQoNCkV2ZXJ5dGhpbmcgZGVwZW5kcyBv biB5b3VyIG5lZWRzLCBkZXNpZ24gcGxhbm5pbmcuIE1heWJlIHRoZW4gc2hhcmluZw0KZGlzayB3 b3VsZCBiZSBiZXR0ZXIgdG8gc2hhcmUgdmlhIE5GUy9pc2NzaS4gT2YgY291cnNlIGlmIHlvdSBo YXZlIG1hbnkNClZNcyBlYWNoIG9mIHRoZW0gaXMgZGlmZmVyZW50IHlvdSB3aWxsIGZhaWwuIEJ1 dCBpZiB5b3UgaGF2ZSBtb3N0bHkNCmhvbW9nZW5lb3VzIGVudmlyb25tZW50IHlvdSBjYW4gdGhp bmsgYWJvdXQgdGhpcyBhcHByb2FjaC4gU3VyZSB5b3UgaGF2ZQ0KdG8gaGF2ZSBwbGFuIGZvciB1 cGdyYWRpbmcgImJhc2UiICJzdGF0aWMiIHNoYXJlZCBPUyBkYXRhLCB5b3UgaGF2ZSB0bw0KaGF2 ZSBwbGFuIGhvdyB0byBpbnN0YWxsIGFkZGl0aW9uYWwgc29mdHdhcmUgKGRpZmZlcmVudCBkZXN0 aW5hdGlvbg0KdGhhbiAvdXNyIG9yIC91c3IvbG9jYWwpLi4uIElmIHlvdSBhbHJlYWR5IGhhdmUg eW91ciBvd24gYnVpbGQgaG9zdA0Kd2hpY2ggYnVpbGRzIGZvciB5b3UgT1MgcGFja2FnZXMgYW5k IHlvdSBoYXZlIGFscmVhZHkgeW91ciBvd24gcGxhbiBmb3INCmRlcGxveW1lbnQsIHlvdSBoYXZl IGRvbmUgZmlyc3Qgc3RlcHMuIElmIHlvdSBkZXBlbmQgb24gdXBncmFkaW5nIGVhY2gNCm1hY2hp bmUgc2VwYXJhdGVseSBmcm9tIEludGVybmV0LCB0aGVuIGZpcnN0IHlvdSBzaG91bGQgcGxhbiB5 b3VyDQplbnZpcm9ubWVudCwgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGV0Yy4NCg0KV2VsbCwg aW4gbWFueSB0aW1lcyBwZW9wbGUgZG8gbm90IGRvIGFueSBwbGFubmluZywgdGhleSBqdXN0IHRo aW5rIHNvbWUNCmdvb2QgdGVjaG5vbG9neSB3b3VsZCBzYXZlIHRoZWlyICJwb29yIiBkZXNpZ24u DQoNCmouDQoNCg0KDQoNCi0tDQoNCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdhcg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KS2FybGkgU2rDtmJlcmcNClN3ZWRpc2ggVW5pdmVyc2l0eSBvZiBBZ3Jp Y3VsdHVyYWwgU2NpZW5jZXMNCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNzIEtyb27DpXN2w6Rn ZW4gOCkNClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRlbg0KUGhvbmU6ICArNDYtKDApMTgtNjcgMTUg NjYNCmthcmxpLnNqb2JlcmdAc2x1LnNlPG1haWx0bzprYXJsaS5zam9iZXJnQGFkbS5zbHUuc2U+ DQoNCg0KDQotLQ0KDQpNZWQgVsOkbmxpZ2EgSMOkbHNuaW5nYXINCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkthcmxpIFNqw7ZiZXJnDQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFs IFNjaWVuY2VzDQpCb3ggNzA3OSAoVmlzaXRpbmcgQWRkcmVzcyBLcm9uw6VzdsOkZ2VuIDgpDQpT LTc1MCAwNyBVcHBzYWxhLCBTd2VkZW4NClBob25lOiAgKzQ2LSgwKTE4LTY3IDE1IDY2DQprYXJs aS5zam9iZXJnQHNsdS5zZTxtYWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlPg0K --_000_5F9E965F5A80BC468BE5F40576769F092A1CD2EDexchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpmcmUgMjAxMy0wNS0z MSBrbG9ja2FuIDA5OjUwICYjNDM7MDEwMCBza3JldiBzdXBvcnRlQGxvZ2ljd29ya3MucHQ6DQo8 YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+U28sIHdlIGNhbiBz YXkgdGhhdCBkZWR1cCBoYXMgbW9yZSBkaXNhZHZhbnRhZ2VzIHRoYW4gYWR2YW50YWdlcy48L2Zv bnQ+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KRm9yIGEgcHJpbWFyeSBzeXN0ZW07IG1vc3Qg ZGVmaW5pdGVseSwgeWVzLjxicj4NCjxicj4NCkJ1dCBmb3IgYSBiYWNrdXAgc3lzdGVtLCB0aGF0 IGhhcyB0b25zIG9mIFJBTSBhbmQgU1NEJ3MgZm9yIGNhY2hlLCBhbmQgeW91IGhhdmUgbG90cyBv ZiB2aXJ0dWFsIG1hY2hpbmVzIHRoYXQgYXJlIGJhc2VkIG9mZiBvZiB0aGUgdGVtcGxhdGUsIG9y IGFyZSB2ZXJ5IG11Y2ggdGhlIHNhbWUsIHRoZW4geW91IGhhdmUgYSByZWFsIHVzZS1jYXNlLiBJ wrRtIGFjdGl2ZSBhdCB0aGUgRnJlZUJTRCBmb3J1bXMgd2hlcmUgb25lIHBlcnNvbiByZXBvcnRz DQogc3RvcmluZyAxNTBUQiBvZiBkYXRhIGluIG9ubHkgMzBUQiBvZiBwaHlzaWNhbCBkaXNrLiBU aGUgYmVzdCBwcmFjdGljZSBvZiBzY3J1YmJpbmcgaXMgb25jZSBhIHdlZWsgb24gJnF1b3Q7ZW50 ZXJwcmlzZSZxdW90OyBzeXN0ZW1zLCB0aG91Z2ggaGUgaXMgb25seSBhYmxlIHRvIGRvIGl0IG9u Y2UgYSBtb250aCwgYmVjYXVzZSB0aGF0wrRzIGhvdyBsb25nIGl0IHRha2VzIGZvciBhIHNjcnVi IHRvIGNvbXBsZXRlIGluIHRoYXQgc3lzdGVtLiBTbyB5b3XCtHZlIGdvdA0KIHRvIGNob29zZSBw ZXJmb3JtYW5jZSBvciBzYXZpbmdzLCB5b3UgY2FuwrR0IGhhdmUgYm90aC48YnI+DQo8YnI+DQo8 YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+QW5kIHdo YXQgYWJvdXQgZGVkdXAgb2YgTmV0YXBwPzwvZm9udD48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+ DQpNdWNoIGJldHRlciBpbXBsZW1lbnRhdGlvbiwgaW4gbXkgb3Bpbmlvbi4gWW91IGFyZSBhYmxl IHNjaGVkdWxlIGRlZHVwLXJ1bnMgdG8gZ28gYXQgbmlnaHQgc28geW91ciB1c2VywrRzIHBlcmZv cm1hbmNlIGlzbsK0dCBpbXBhY3RlZCwgYW5kIHlvdSBnZXQgdGhlIHNhdmluZ3MuIFRoZSBxdWVz dGlvbiBpcyBpZiB5b3UgdmFsdWUgdGhlIHNhdmluZ3MgZW5vdWdoIHRvIHRha2Ugb24gcHJpY2Ut dGFnIHRoYXQgaXMgTmV0QXBwLiBPciBqdXN0IGJ1aWxkDQogeW91ciBvd24gRnJlZUJTRC9aRlMg c2VydmVyIHdpdGggY29tcHJlc3Npb24gZW5hYmxlZCBhbmQgYnV5IGluIHN0YW5kYXJkIEhERCdz IGZyb20gYW55d2hlcmUuLi4gV2UgZGlkOyk8YnI+DQo8YnI+DQovS2FybGk8YnI+DQo8YnI+DQo8 YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Sm9zZTwv Zm9udD48YnI+DQo8YnI+DQo8aHIgYWxpZ249ImNlbnRlciI+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSB0eXBlPSJDSVRFIj48Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+RnJvbTogPC9mb250 PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+JnF1b3Q7S2FybGkgU2rDtmJlcmcmcXVvdDsgJmx0 O0thcmxpLlNqb2JlcmdAc2x1LnNlJmd0OzwvZm9udD48YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAw MDAwMCI+VG86IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPnN1cG9ydGVAbG9naWN3 b3Jrcy5wdDwvZm9udD48YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+Q2M6IDwvZm9udD48 L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiZxdW90O0ppcmkgQmVsa2EmcXVvdDsgJmx0O2piZWxr YUByZWRoYXQuY29tJmd0OywgdXNlcnNAb3ZpcnQub3JnPC9mb250Pjxicj4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDAwIj5TZW50OiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAwIj5RdWlu dGEtZmVpcmEsIDMwIGRlIE1haW8gZGUgMjAxMyA4OjMzOjE5PC9mb250Pjxicj4NCjxiPjxmb250 IGNvbG9yPSIjMDAwMDAwIj5TdWJqZWN0OiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAw Ij5SZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNvbG9y PSIjMDAwMDAwIj5vbnMgMjAxMy0wNS0yOSBrbG9ja2FuIDA5OjU5ICYjNDM7MDEwMCBza3JldiBz dXBvcnRlQGxvZ2ljd29ya3MucHQ6DQo8L2ZvbnQ+PGJyPg0KPGJsb2NrcXVvdGU+PGZvbnQgY29s b3I9IiMwMDAwMDAiPkFic29sdXRlbHkgYWdyZWUgd2l0aCB5b3UsIHBsYW5uaW5nIGlzIHRoZSBi ZXN0IHRoaW5nIHRvIGRvLCBidXQgbm9ybWFsbHkgcGVvcGxlIHdhbnQgYSBwbHVnJ24ncGxheSBz eXN0ZW0gd2l0aCBhbGwgaW5jbHVkZWQsIGJlY2F1c2UgdGhlcmUgaXMgbm90IG11Y2ggdGltZSB0 byB0aGluayBhbmQgcGxhbm5pbmcsIGFuZCB0aGVyZSBhcmUgbWFueSBjb21wYW5pZXMgdGhhdCBr bm93IGhvdw0KIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgcGVvcGxlIGNoYXJhY3RlcmlzdGlj cy48L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPkFueSB3YXksIEkgdGhpbmsgYW5v dGhlciBzb2x1dGlvbiBmb3IgZGVkdXAgaXMgRnJlZU5BUyB1c2luZyBaRlMuPC9mb250Pjxicj4N CjwvYmxvY2txdW90ZT4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5GcmVlTkFTIGlzIGp1 c3QgRnJlZUJTRCB3aXRoIGEgZmFuY3kgd2ViLXVpIG9udG9wLCBzbyBpdMK0cyBuZWl0aGVyIG1v cmUgb3IgbGVzcyBvZiBaRlMgdGhhbiB5b3Ugd291bGQgaGF2ZSBvdGhlcndpc2UsIEFuZCByZWdh cmRpbmcgZGVkdXAgaW4gWkZTOyBKdXN0IGRvbsK0dCwgaXTCtHMgbm90IHdvcnRoIGl0ISBJdMK0 cyBzYWlkIHRoYXQgaXQNCjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGI+bWF5PC9iPjwv Zm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+IGluY3JlYXNlIHBlcmZvcm1hbmNlIHdoZW4geW91 IGhhdmUgYSB2ZXJ5IHN1aXRhYmxlIHVzZWNhc2UsIGUuZy4gZXZlcnl0aGluZw0KPC9mb250Pjxm b250IGNvbG9yPSIjMDAwMDAwIj48Yj5leGFjdGx5PC9iPjwvZm9udD48Zm9udCBjb2xvcj0iIzAw MDAwMCI+IHRoZSBzYW1lIG92ZXIgYW5kIG92ZXIuIFdoYXTCtHMgbm90IHNhaWQgaXMgdGhhdCBz Y3J1YmJpbmcgYW5kIHJlc2lsdmVyaW5nIHNsb3dzIGRvd24gdG8gYSBzbmFpbCAoZnJvbSBodW5k cmVkcyBvZiBNQi9zLCBvciBHQiBpZiB5b3VyIHN5c3RlbSBpcyBsYXJnZSBlbm91Z2gsIGRvd24g dG8gbGVzcyB0aGFuIDEwKSwganVzdA0KIGZyb20gZGVkdXAuIEFsc28gZGVsZXRpbmcgc25hcHNo b3RzIG9mIGRhdGFzZXRzIHRoYXQgaGF2ZShvciBoYXZlIGhhZCkgZGVkdXAgb24gY2FuIGtpbGwg dGhlIGVudGlyZSBzeXN0ZW0sIGFuZCB3aGVuIEkgc2F5IGtpbGwsIEkgbWVhbiByZWFsbHkgZnVi YXIuIEJlZW4gdGhlcmUsIHJlZ3JldHRlZCB0aGF0Li4uIE5vdywgY29tcHJlc3Npb24gb24gdGhl IG90aGVyIGhhbmQsIHlvdSBnZXQgYmFzaWNhbGx5IGZvciBmcmVlIGFuZCBnaXZlcyBkZWNlbnQN CiBzYXZpbmdzLCBJIGhpZ2hseSByZWNvbW1lbmQgdGhhdC48L2ZvbnQ+PGJyPg0KPGJyPg0KPGZv bnQgY29sb3I9IiMwMDAwMDAiPi9LYXJsaTwvZm9udD48YnI+DQo8YnI+DQo8YmxvY2txdW90ZT48 YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Sm9zZTwvZm9udD48YnI+DQo8YnI+DQo8YnI+DQo8 aHIgYWxpZ249ImNlbnRlciI+DQo8YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+RnJvbTog PC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+JnF1b3Q7SmlyaSBCZWxrYSZxdW90OyAm bHQ7amJlbGthQHJlZGhhdC5jb20mZ3Q7PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAw MDAwIj5UbzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+c3Vwb3J0ZUBsb2dpY3dv cmtzLnB0PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5DYzogPC9mb250Pjwv Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+dXNlcnNAb3ZpcnQub3JnPC9mb250Pjxicj4NCjxiPjxm b250IGNvbG9yPSIjMDAwMDAwIj5TZW50OiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAw Ij5RdWFydGEtZmVpcmEsIDI5IGRlIE1haW8gZGUgMjAxMyA3OjMzOjEwPC9mb250Pjxicj4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDAwIj5TdWJqZWN0OiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIj MDAwMDAwIj5SZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uPC9mb250Pjxicj4NCjxicj4NCjxmb250 IGNvbG9yPSIjMDAwMDAwIj5PbiBUdWUsIDI4IE1heSAyMDEzIDE0OjI5OjA1ICYjNDM7MDEwMCAo V0VTVCk8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPnN1cG9ydGVAbG9naWN3b3Jr cy5wdCB3cm90ZTo8L2ZvbnQ+PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPiZndDsg VGhhdCdzIHdoeSBJJ20gbWFraW5nIHRoaXMgcXVlc3Rpb25zLCB0byBkZW15c3RpZnkgc29tZSBi dXp6d29yZHMgYXJvdW5kIGhlcmUuPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj4m Z3Q7IEJ1dCBpZiB5b3UgaGF2ZSBhIHN0cm9uZyBhbmQgZ29vZCB0ZWNobm9sb2d5IHdoeSBub3Qg Y3JlYXRlIGJ1enp3b3JkcyB0byBnZXQgaW50byBhcyBtYW55IHBlb3BsZSBhcyBwb3NzaWJsZT8g d2l0aG91dCB0cmFwcGVkIHRoZW0uPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj4m Z3Q7IFNoYXJlIGEgZGlzayBjb250YWluaW5nICZxdW90O3N0YXRpYyZxdW90OyBkYXRhIGlzIGEg Z29vZCBpZGVhLCBkbyB5b3Uga25vdyBmcm9tIHdoZXJlIEkgY2FuIHN0YXJ0PzwvZm9udD48YnI+ DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+RXZlcnl0aGluZyBkZXBlbmRzIG9uIHlvdXIg bmVlZHMsIGRlc2lnbiBwbGFubmluZy4gTWF5YmUgdGhlbiBzaGFyaW5nPC9mb250Pjxicj4NCjxm b250IGNvbG9yPSIjMDAwMDAwIj5kaXNrIHdvdWxkIGJlIGJldHRlciB0byBzaGFyZSB2aWEgTkZT L2lzY3NpLiBPZiBjb3Vyc2UgaWYgeW91IGhhdmUgbWFueTwvZm9udD48YnI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+Vk1zIGVhY2ggb2YgdGhlbSBpcyBkaWZmZXJlbnQgeW91IHdpbGwgZmFpbC4g QnV0IGlmIHlvdSBoYXZlIG1vc3RseTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+ aG9tb2dlbmVvdXMgZW52aXJvbm1lbnQgeW91IGNhbiB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNo LiBTdXJlIHlvdSBoYXZlPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj50byBoYXZl IHBsYW4gZm9yIHVwZ3JhZGluZyAmcXVvdDtiYXNlJnF1b3Q7ICZxdW90O3N0YXRpYyZxdW90OyBz aGFyZWQgT1MgZGF0YSwgeW91IGhhdmUgdG88L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAw MDAiPmhhdmUgcGxhbiBob3cgdG8gaW5zdGFsbCBhZGRpdGlvbmFsIHNvZnR3YXJlIChkaWZmZXJl bnQgZGVzdGluYXRpb248L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPnRoYW4gL3Vz ciBvciAvdXNyL2xvY2FsKS4uLiBJZiB5b3UgYWxyZWFkeSBoYXZlIHlvdXIgb3duIGJ1aWxkIGhv c3Q8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPndoaWNoIGJ1aWxkcyBmb3IgeW91 IE9TIHBhY2thZ2VzIGFuZCB5b3UgaGF2ZSBhbHJlYWR5IHlvdXIgb3duIHBsYW4gZm9yPC9mb250 Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5kZXBsb3ltZW50LCB5b3UgaGF2ZSBkb25lIGZp cnN0IHN0ZXBzLiBJZiB5b3UgZGVwZW5kIG9uIHVwZ3JhZGluZyBlYWNoPC9mb250Pjxicj4NCjxm b250IGNvbG9yPSIjMDAwMDAwIj5tYWNoaW5lIHNlcGFyYXRlbHkgZnJvbSBJbnRlcm5ldCwgdGhl biBmaXJzdCB5b3Ugc2hvdWxkIHBsYW4geW91cjwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAw MDAwMCI+ZW52aXJvbm1lbnQsIGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBldGMuPC9mb250Pjxi cj4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5XZWxsLCBpbiBtYW55IHRpbWVzIHBlb3Bs ZSBkbyBub3QgZG8gYW55IHBsYW5uaW5nLCB0aGV5IGp1c3QgdGhpbmsgc29tZTwvZm9udD48YnI+ DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Z29vZCB0ZWNobm9sb2d5IHdvdWxkIHNhdmUgdGhlaXIg JnF1b3Q7cG9vciZxdW90OyBkZXNpZ24uPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIj MDAwMDAwIj5qLjwvZm9udD48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 YnI+DQo8dGFibGUgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQ+LS0gPGJyPg0KPGJyPg0KTWVkIFbDpG5saWdhIEjDpGxzbmlu Z2FyPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkthcmxpIFNqw7ZiZXJnPGJyPg0K U3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlczxicj4NCkJveCA3MDc5 IChWaXNpdGluZyBBZGRyZXNzIEtyb27DpXN2w6RnZW4gOCk8YnI+DQpTLTc1MCAwNyBVcHBzYWxh LCBTd2VkZW48YnI+DQpQaG9uZTogJm5ic3A7JiM0Mzs0Ni0oMCkxOC02NyAxNSA2Njxicj4NCjxh IGhyZWY9Im1haWx0bzprYXJsaS5zam9iZXJnQGFkbS5zbHUuc2UiPmthcmxpLnNqb2JlcmdAc2x1 LnNlPC9hPiA8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0K PHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkPi0tIDxicj4NCjxicj4NCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdhcjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpLYXJsaSBTasO2YmVyZzxicj4NClN3ZWRp c2ggVW5pdmVyc2l0eSBvZiBBZ3JpY3VsdHVyYWwgU2NpZW5jZXM8YnI+DQpCb3ggNzA3OSAoVmlz aXRpbmcgQWRkcmVzcyBLcm9uw6VzdsOkZ2VuIDgpPGJyPg0KUy03NTAgMDcgVXBwc2FsYSwgU3dl ZGVuPGJyPg0KUGhvbmU6ICZuYnNwOyYjNDM7NDYtKDApMTgtNjcgMTUgNjY8YnI+DQo8YSBocmVm PSJtYWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlIj5rYXJsaS5zam9iZXJnQHNsdS5zZTwv YT4gPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F9E965F5A80BC468BE5F40576769F092A1CD2EDexchange21_--
------=_Part_1134_11907452.1369996394775 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks a lot Karli, you make my mind clear about deduplication, once again = we cannot have the best of both worlds.=20 I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running o= n Linux, has no better performance but supports DRDB.=20 Jose=20 ----- Original Message ----- From: "Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se>=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" <jbelka@redhat.com>, users@ovirt.org=20 Sent: Sexta-feira, 31 de Maio de 2013 10:45:41=20 Subject: Re: [Users] deduplication=20 fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt:=20 So, we can say that dedup has more disadvantages than advantages.=20 For a primary system; most definitely, yes.=20 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4= s how long it takes for a scrub to complete in that system. So you=C2=B4ve = got to choose performance or savings, you can=C2=B4t have both.=20 <blockquote> And what about dedup of Netapp?=20 </blockquote> Much better implementation, in my opinion. You are able schedule dedup-runs= to go at night so your user=C2=B4s performance isn=C2=B4t impacted, and yo= u 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;)=20 /Karli=20 <blockquote> Jose=20 </blockquote> <blockquote> From: "Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se>=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" <jbelka@redhat.com>, users@ovirt.org=20 Sent: Quinta-feira, 30 de Maio de 2013 8:33:19=20 Subject: Re: [Users] deduplication=20 ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt:=20 <blockquote> Absolutely agree with you, planning is the best thing to do, but normally p= eople want a plug'n'play system with all included, because there is not muc= h time to think and planning, and there are many companies that know how to= take advantage of this people characteristics.=20 Any way, I think another solution for dedup is FreeNAS using ZFS.=20 </blockquote> FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it may increa= se performance when you have a very suitable usecase, e.g. everything exact= ly the same over and over. What=C2=B4s not said is that scrubbing and resil= vering slows down to a snail (from hundreds of MB/s, or GB if your system i= s large enough, down to less than 10), just from dedup. Also deleting snaps= hots 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... N= ow, compression on the other hand, you get basically for free and gives dec= ent savings, I highly recommend that.=20 /Karli=20 <blockquote> Jose=20 From: "Jiri Belka" <jbelka@redhat.com>=20 To: suporte@logicworks.pt=20 Cc: users@ovirt.org=20 Sent: Quarta-feira, 29 de Maio de 2013 7:33:10=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 14:29:05 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20
That's why I'm making this questions, to demystify some buzzwords around = here.=20 But if you have a strong and good technology why not create buzzwords to = get into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wh= ere I can start?=20
Everything depends on your needs, design planning. Maybe then sharing=20 disk would be better to share via NFS/iscsi. Of course if you have many=20 VMs each of them is different you will fail. But if you have mostly=20 homogeneous environment you can think about this approach. Sure you have=20 to have plan for upgrading "base" "static" shared OS data, you have to=20 have plan how to install additional software (different destination=20 than /usr or /usr/local)... If you already have your own build host=20 which builds for you OS packages and you have already your own plan for=20 deployment, you have done first steps. If you depend on upgrading each=20 machine separately from Internet, then first you should plan your=20 environment, configuration management etc.=20 Well, in many times people do not do any planning, they just think some=20 good technology would save their "poor" design.=20 j.=20 </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 </blockquote> <blockquote> </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 ------=_Part_1134_11907452.1369996394775 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>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 id=3D"zwchr"><= div style=3D"color: rgb(0, 0, 0); font-weight: normal; font-style: normal; = text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: = 12pt;"><b>From: </b>"Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se><br><b=
To: </b>suporte@logicworks.pt<br><b>Cc: </b>"Jiri Belka" <jbelka@redhat= .com>, users@ovirt.org<br><b>Sent: </b>Sexta-feira, 31 de Maio de 2013 1= 0:45:41<br><b>Subject: </b>Re: [Users] deduplication<br><br>
fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt: <blockquote><font color=3D"#000000">So, we can say that dedup has more disa= dvantages 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4s how long it takes for a scrub to c= omplete in that system. So you=C2=B4ve got to choose performance or savings, you can=C2=B4t have both.<br> <br> <blockquote><br> <font color=3D"#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=C2=B4s performance isn=C2=B4t impacted, and yo= u 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 H= DD's from anywhere... We did;)<br> <br> /Karli<br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <hr align=3D"center"> </blockquote> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Karli Sj=C3=B6berg" <Karli.Sjoberg@slu.se></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000">suporte@l= ogicworks.pt</font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">"Jiri Bel= ka" <jbelka@redhat.com>, users@ovirt.org</font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quinta-= feira, 30 de Maio de 2013 8:33:19</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">ons 2013-05-29 klockan 09:59 +0100 skrev suporte@lo= gicworks.pt: </font><br> <blockquote><font color=3D"#000000">Absolutely agree with you, planning is = the best thing to do, but normally people want a plug'n'play system with al= l 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=3D"#000000">Any way, I think another solution for dedup is Free= NAS using ZFS.</font><br> </blockquote> <br> <font color=3D"#000000">FreeNAS is just FreeBSD with a fancy web-ui ontop, = so it=C2=B4s neither more or less of ZFS than you would have otherwise, And= regarding dedup in ZFS; Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s= said that it </font><font color=3D"#000000"><b>may</b></font><font color=3D"#000000"> in= crease performance when you have a very suitable usecase, e.g. everything </font><font color=3D"#000000"><b>exactly</b></font><font color=3D"#000000"=
the same over and over. What=C2=B4s not said is that scrubbing and resilv= ering 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) ded= up 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=3D"#000000">/Karli</font><br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <br> <hr align=3D"center"> <br> <b><font color=3D"#000000">From: </font></b><font color=3D"#000000">"Jiri B= elka" <jbelka@redhat.com></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000">suporte@l= ogicworks.pt</font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">users@ovi= rt.org</font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quarta-= feira, 29 de Maio de 2013 7:33:10</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br=
<font color=3D"#000000">suporte@logicworks.pt wrote:</font><br> <br> <font color=3D"#000000">> That's why I'm making this questions, to demys= tify some buzzwords around here.</font><br> <font color=3D"#000000">> But if you have a strong and good technology w= hy not create buzzwords to get into as many people as possible? without tra= pped them.</font><br> <font color=3D"#000000">> Share a disk containing "static" data is a goo= d idea, do you know from where I can start?</font><br> <br> <font color=3D"#000000">Everything depends on your needs, design planning. = Maybe then sharing</font><br> <font color=3D"#000000">disk would be better to share via NFS/iscsi. Of cou= rse if you have many</font><br> <font color=3D"#000000">VMs each of them is different you will fail. But if= you have mostly</font><br> <font color=3D"#000000">homogeneous environment you can think about this ap= proach. Sure you have</font><br> <font color=3D"#000000">to have plan for upgrading "base" "static" shared O= S data, you have to</font><br> <font color=3D"#000000">have plan how to install additional software (diffe= rent destination</font><br> <font color=3D"#000000">than /usr or /usr/local)... If you already have you= r own build host</font><br> <font color=3D"#000000">which builds for you OS packages and you have alrea= dy your own plan for</font><br> <font color=3D"#000000">deployment, you have done first steps. If you depen= d on upgrading each</font><br> <font color=3D"#000000">machine separately from Internet, then first you sh= ould plan your</font><br> <font color=3D"#000000">environment, configuration management etc.</font><b= r> <br> <font color=3D"#000000">Well, in many times people do not do any planning, = they just think some</font><br> <font color=3D"#000000">good technology would save their "poor" design.</fo= nt><br> <br> <font color=3D"#000000">j.</font><br> <br> <br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </blockquote> <blockquote><br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </div><br></div></body></html> ------=_Part_1134_11907452.1369996394775--
Hello Jose, 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. Juanjo. On Fri, May 31, 2013 at 12:33 PM, <suporte@logicworks.pt> wrote:
Thanks a lot Karli, you make my mind clear about deduplication, once again we cannot have the best of both worlds.
I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running on Linux, has no better performance but supports DRDB.
Jose
------------------------------ *From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Sexta-feira, 31 de Maio de 2013 10:45:41 *Subject: *Re: [Users] deduplication
fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt:
So, we can say that dedup has more disadvantages than advantages.
For a primary system; most definitely, yes.
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.
And what about dedup of Netapp?
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;)
/Karli
Jose
------------------------------
*From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Quinta-feira, 30 de Maio de 2013 8:33:19 *Subject: *Re: [Users] deduplication
ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt:
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. Any way, I think another solution for dedup is FreeNAS using ZFS.
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 *may* increase performance when you have a very suitable usecase, e.g. everything *exactly* 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.
/Karli
Jose
------------------------------
*From: *"Jiri Belka" <jbelka@redhat.com> *To: *suporte@logicworks.pt *Cc: *users@ovirt.org *Sent: *Quarta-feira, 29 de Maio de 2013 7:33:10 *Subject: *Re: [Users] deduplication
On Tue, 28 May 2013 14:29:05 +0100 (WEST) suporte@logicworks.pt wrote:
That's why I'm making this questions, to demystify some buzzwords around here. But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them. Share a disk containing "static" data is a good idea, do you know from where I can start?
Everything depends on your needs, design planning. Maybe then sharing disk would be better to share via NFS/iscsi. Of course if you have many VMs each of them is different you will fail. But if you have mostly homogeneous environment you can think about this approach. Sure you have to have plan for upgrading "base" "static" shared OS data, you have to have plan how to install additional software (different destination than /usr or /usr/local)... If you already have your own build host which builds for you OS packages and you have already your own plan for deployment, you have done first steps. If you depend on upgrading each machine separately from Internet, then first you should plan your environment, configuration management etc.
Well, in many times people do not do any planning, they just think some good technology would save their "poor" design.
j.
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
------=_Part_1742_408268.1370275951382 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juan,=20 thanks for your info, I'll try to test FreeNAS with compression. Do you use= it with iSCSI or NFS?=20 Jose=20 ----- Original Message ----- From: "Juan Jose" <jj197005@gmail.com>=20 To: suporte@logicworks.pt, users@ovirt.org=20 Sent: Segunda-feira, 3 de Junho de 2013 13:37:21=20 Subject: Re: [Users] deduplication=20 Hello Jose,=20 We also have FreeNAS working in our infraestructure, with about 3 TB and ZF= S. 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 an= d other paravirtualized, and some Windows Server machine all about 2 years = in production without any problem. My idea is connect this infrastructure w= ith oVirt wo be able to have some resources for test VMs in that. Only want= ed to share as another FreeNas success experience.=20 Juanjo.=20 On Fri, May 31, 2013 at 12:33 PM, < suporte@logicworks.pt > wrote:=20 Thanks a lot Karli, you make my mind clear about deduplication, once again = we cannot have the best of both worlds.=20 I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running o= n Linux, has no better performance but supports DRDB.=20 Jose=20 From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Sexta-feira, 31 de Maio de 2013 10:45:41=20 Subject: Re: [Users] deduplication=20 fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt :=20 <blockquote> So, we can say that dedup has more disadvantages than advantages.=20 For a primary system; most definitely, yes.=20 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4= s how long it takes for a scrub to complete in that system. So you=C2=B4ve = got to choose performance or savings, you can=C2=B4t have both.=20 <blockquote> And what about dedup of Netapp?=20 </blockquote> Much better implementation, in my opinion. You are able schedule dedup-runs= to go at night so your user=C2=B4s performance isn=C2=B4t impacted, and yo= u 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;)=20 /Karli=20 <blockquote> Jose=20 </blockquote> <blockquote> From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Quinta-feira, 30 de Maio de 2013 8:33:19=20 Subject: Re: [Users] deduplication=20 ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt :=20 <blockquote> Absolutely agree with you, planning is the best thing to do, but normally p= eople want a plug'n'play system with all included, because there is not muc= h time to think and planning, and there are many companies that know how to= take advantage of this people characteristics.=20 Any way, I think another solution for dedup is FreeNAS using ZFS.=20 </blockquote> FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it may increa= se performance when you have a very suitable usecase, e.g. everything exact= ly the same over and over. What=C2=B4s not said is that scrubbing and resil= vering slows down to a snail (from hundreds of MB/s, or GB if your system i= s large enough, down to less than 10), just from dedup. Also deleting snaps= hots 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... N= ow, compression on the other hand, you get basically for free and gives dec= ent savings, I highly recommend that.=20 /Karli=20 <blockquote> Jose=20 From: "Jiri Belka" < jbelka@redhat.com >=20 To: suporte@logicworks.pt=20 Cc: users@ovirt.org=20 Sent: Quarta-feira, 29 de Maio de 2013 7:33:10=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 14:29:05 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20
That's why I'm making this questions, to demystify some buzzwords around = here.=20 But if you have a strong and good technology why not create buzzwords to = get into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wh= ere I can start?=20
Everything depends on your needs, design planning. Maybe then sharing=20 disk would be better to share via NFS/iscsi. Of course if you have many=20 VMs each of them is different you will fail. But if you have mostly=20 homogeneous environment you can think about this approach. Sure you have=20 to have plan for upgrading "base" "static" shared OS data, you have to=20 have plan how to install additional software (different destination=20 than /usr or /usr/local)... If you already have your own build host=20 which builds for you OS packages and you have already your own plan for=20 deployment, you have done first steps. If you depend on upgrading each=20 machine separately from Internet, then first you should plan your=20 environment, configuration management etc.=20 Well, in many times people do not do any planning, they just think some=20 good technology would save their "poor" design.=20 j.=20 </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 </blockquote> <blockquote> </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 </blockquote> ------=_Part_1742_408268.1370275951382 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>Hi Juan,<br><br>thanks for your info, I'll try to test FreeNAS = with compression. Do you use it with iSCSI or NFS?<br><br>Jose<br><br><hr i= d=3D"zwchr"><div style=3D"color: rgb(0, 0, 0); font-weight: normal; font-st= yle: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif= ; font-size: 12pt;"><b>From: </b>"Juan Jose" <jj197005@gmail.com><br>= <b>To: </b>suporte@logicworks.pt, users@ovirt.org<br><b>Sent: </b>Segunda-f= eira, 3 de Junho de 2013 13:37:21<br><b>Subject: </b>Re: [Users] deduplicat= ion<br><br><div dir=3D"ltr"><br><div>Hello Jose,</div><div><br></div><div>W= e 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 i= n production without any problem. My idea is connect this infrastructure wi= th oVirt wo be able to have some resources for test VMs in that. Only wante= d to share as another FreeNas success experience.</div> <div><br></div><div>Juanjo.</div></div><div class=3D"gmail_extra"><br><br><= div class=3D"gmail_quote">On Fri, May 31, 2013 at 12:33 PM, <span dir=3D"l= tr"><<a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@= logicworks.pt</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style= =3D"font-size: 10pt; font-family: arial,helvetica,sans-serif;">Thanks a lot= Karli, you make my mind clear about deduplication, once again we cannot ha= ve the best of both worlds.<br> <br>I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, runni= ng on Linux, has no better performance but supports DRDB.<br><br>Jose<br><b= r><hr><div style=3D"font-size: 12pt; font-style: normal; font-family: Helve= tica,Arial,sans-serif; text-decoration: none; font-weight: normal;"> <div class=3D"im"><b>From: </b>"Karli Sj=C3=B6berg" <<a href=3D"mailto:K= arli.Sjoberg@slu.se" target=3D"_blank">Karli.Sjoberg@slu.se</a>><br><b>T= o: </b><a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@l= ogicworks.pt</a><br> <b>Cc: </b>"Jiri Belka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"= _blank">jbelka@redhat.com</a>>, <a href=3D"mailto:users@ovirt.org" targe= t=3D"_blank">users@ovirt.org</a><br></div><b>Sent: </b>Sexta-feira, 31 de M= aio de 2013 10:45:41<br> <b>Subject: </b>Re: [Users] deduplication<div><div class=3D"h5"><br><br> fre 2013-05-31 klockan 09:50 +0100 skrev <a href=3D"mailto:suporte@logicwor= ks.pt" target=3D"_blank">suporte@logicworks.pt</a>: <blockquote><font color=3D"#000000">So, we can say that dedup has more disa= dvantages 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4s how long it takes for a scrub to c= omplete in that system. So you=C2=B4ve got to choose performance or savings, you can=C2=B4t have both.<br> <br> <blockquote><br> <font color=3D"#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=C2=B4s performance isn=C2=B4t impacted, and yo= u 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 H= DD's from anywhere... We did;)<br> <br> /Karli<br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <hr align=3D"center"> </blockquote> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Karli Sj=C3=B6berg" <<a href=3D"mailto:Karli.Sjoberg@slu.se" targe= t=3D"_blank">Karli.Sjoberg@slu.se</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">"Jiri Bel= ka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@redha= t.com</a>>, <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@o= virt.org</a></font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quinta-= feira, 30 de Maio de 2013 8:33:19</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">ons 2013-05-29 klockan 09:59 +0100 skrev <a href=3D= "mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</a>: </font><br> <blockquote><font color=3D"#000000">Absolutely agree with you, planning is = the best thing to do, but normally people want a plug'n'play system with al= l 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=3D"#000000">Any way, I think another solution for dedup is Free= NAS using ZFS.</font><br> </blockquote> <br> <font color=3D"#000000">FreeNAS is just FreeBSD with a fancy web-ui ontop, = so it=C2=B4s neither more or less of ZFS than you would have otherwise, And= regarding dedup in ZFS; Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s= said that it </font><font color=3D"#000000"><b>may</b></font><font color=3D"#000000"> in= crease performance when you have a very suitable usecase, e.g. everything </font><font color=3D"#000000"><b>exactly</b></font><font color=3D"#000000"=
the same over and over. What=C2=B4s not said is that scrubbing and resilv= ering 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) ded= up 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=3D"#000000">/Karli</font><br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <br> <hr align=3D"center"> <br> <b><font color=3D"#000000">From: </font></b><font color=3D"#000000">"Jiri B= elka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@red= hat.com</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000"><a href= =3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a></font><br=
<b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quarta-= feira, 29 de Maio de 2013 7:33:10</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br=
<font color=3D"#000000"><a href=3D"mailto:suporte@logicworks.pt" target=3D"= _blank">suporte@logicworks.pt</a> wrote:</font><br> <br> <font color=3D"#000000">> That's why I'm making this questions, to demys= tify some buzzwords around here.</font><br> <font color=3D"#000000">> But if you have a strong and good technology w= hy not create buzzwords to get into as many people as possible? without tra= pped them.</font><br> <font color=3D"#000000">> Share a disk containing "static" data is a goo= d idea, do you know from where I can start?</font><br> <br> <font color=3D"#000000">Everything depends on your needs, design planning. = Maybe then sharing</font><br> <font color=3D"#000000">disk would be better to share via NFS/iscsi. Of cou= rse if you have many</font><br> <font color=3D"#000000">VMs each of them is different you will fail. But if= you have mostly</font><br> <font color=3D"#000000">homogeneous environment you can think about this ap= proach. Sure you have</font><br> <font color=3D"#000000">to have plan for upgrading "base" "static" shared O= S data, you have to</font><br> <font color=3D"#000000">have plan how to install additional software (diffe= rent destination</font><br> <font color=3D"#000000">than /usr or /usr/local)... If you already have you= r own build host</font><br> <font color=3D"#000000">which builds for you OS packages and you have alrea= dy your own plan for</font><br> <font color=3D"#000000">deployment, you have done first steps. If you depen= d on upgrading each</font><br> <font color=3D"#000000">machine separately from Internet, then first you sh= ould plan your</font><br> <font color=3D"#000000">environment, configuration management etc.</font><b= r> <br> <font color=3D"#000000">Well, in many times people do not do any planning, = they just think some</font><br> <font color=3D"#000000">good technology would save their "poor" design.</fo= nt><br> <br> <font color=3D"#000000">j.</font><br> <br> <br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </blockquote> <blockquote><br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </div></div></div><br></div></div><br>_____________________________________= __________<br> Users mailing list<br> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.org</a><br=
<a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"=
http://lists.ovirt.org/mailman/listinfo/users</a><br> <br></blockquote></div><br></div> </div><br></div></body></html> ------=_Part_1742_408268.1370275951382--
Just wanted to add that Freenas is great. I use it with NFS and ISCSI and it works well. What I will say, on the HP DNS-320 I have in it I have had to go to the command prompt to fix some multipathing issues when I first add a disk but I beleive that is just a product of the cciss controller driver in that server. On Mon, Jun 3, 2013 at 12:12 PM, <suporte@logicworks.pt> wrote:
Hi Juan,
thanks for your info, I'll try to test FreeNAS with compression. Do you use it with iSCSI or NFS?
Jose
------------------------------ *From: *"Juan Jose" <jj197005@gmail.com> *To: *suporte@logicworks.pt, users@ovirt.org *Sent: *Segunda-feira, 3 de Junho de 2013 13:37:21 *Subject: *Re: [Users] deduplication
Hello Jose,
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.
Juanjo.
On Fri, May 31, 2013 at 12:33 PM, <suporte@logicworks.pt> wrote:
Thanks a lot Karli, you make my mind clear about deduplication, once again we cannot have the best of both worlds.
I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running on Linux, has no better performance but supports DRDB.
Jose
------------------------------ *From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Sexta-feira, 31 de Maio de 2013 10:45:41 *Subject: *Re: [Users] deduplication
fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt:
So, we can say that dedup has more disadvantages than advantages.
For a primary system; most definitely, yes.
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.
And what about dedup of Netapp?
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;)
/Karli
Jose
------------------------------
*From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Quinta-feira, 30 de Maio de 2013 8:33:19 *Subject: *Re: [Users] deduplication
ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt:
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. Any way, I think another solution for dedup is FreeNAS using ZFS.
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 *may* increase performance when you have a very suitable usecase, e.g. everything * exactly* 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.
/Karli
Jose
------------------------------
*From: *"Jiri Belka" <jbelka@redhat.com> *To: *suporte@logicworks.pt *Cc: *users@ovirt.org *Sent: *Quarta-feira, 29 de Maio de 2013 7:33:10 *Subject: *Re: [Users] deduplication
On Tue, 28 May 2013 14:29:05 +0100 (WEST) suporte@logicworks.pt wrote:
That's why I'm making this questions, to demystify some buzzwords around here. But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them. Share a disk containing "static" data is a good idea, do you know from where I can start?
Everything depends on your needs, design planning. Maybe then sharing disk would be better to share via NFS/iscsi. Of course if you have many VMs each of them is different you will fail. But if you have mostly homogeneous environment you can think about this approach. Sure you have to have plan for upgrading "base" "static" shared OS data, you have to have plan how to install additional software (different destination than /usr or /usr/local)... If you already have your own build host which builds for you OS packages and you have already your own plan for deployment, you have done first steps. If you depend on upgrading each machine separately from Internet, then first you should plan your environment, configuration management etc.
Well, in many times people do not do any planning, they just think some good technology would save their "poor" design.
j.
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Chris Noffsinger
------=_Part_1980_16023178.1370280384707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we have a hardware RAID controller will we need RAID-Z ?=20 Jose=20 ----- Original Message ----- From: "Chris Noffsinger" <cnoffsin@gmail.com>=20 To: suporte@logicworks.pt=20 Cc: "Juan Jose" <jj197005@gmail.com>, users@ovirt.org=20 Sent: Segunda-feira, 3 de Junho de 2013 17:16:55=20 Subject: Re: [Users] deduplication=20 Just wanted to add that Freenas is great. I use it with NFS and ISCSI and i= t works well. What I will say, on the HP DNS-320 I have in it I have had to= go to the command prompt to fix some multipathing issues when I first add = a disk but I beleive that is just a product of the cciss controller driver = in that server.=20 On Mon, Jun 3, 2013 at 12:12 PM, < suporte@logicworks.pt > wrote:=20 Hi Juan,=20 thanks for your info, I'll try to test FreeNAS with compression. Do you use= it with iSCSI or NFS?=20 Jose=20 From: "Juan Jose" < jj197005@gmail.com >=20 To: suporte@logicworks.pt , users@ovirt.org=20 Sent: Segunda-feira, 3 de Junho de 2013 13:37:21=20 Subject: Re: [Users] deduplication=20 Hello Jose,=20 We also have FreeNAS working in our infraestructure, with about 3 TB and ZF= S. 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 an= d other paravirtualized, and some Windows Server machine all about 2 years = in production without any problem. My idea is connect this infrastructure w= ith oVirt wo be able to have some resources for test VMs in that. Only want= ed to share as another FreeNas success experience.=20 Juanjo.=20 On Fri, May 31, 2013 at 12:33 PM, < suporte@logicworks.pt > wrote:=20 <blockquote> Thanks a lot Karli, you make my mind clear about deduplication, once again = we cannot have the best of both worlds.=20 I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running o= n Linux, has no better performance but supports DRDB.=20 Jose=20 From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Sexta-feira, 31 de Maio de 2013 10:45:41=20 Subject: Re: [Users] deduplication=20 fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt :=20 <blockquote> So, we can say that dedup has more disadvantages than advantages.=20 For a primary system; most definitely, yes.=20 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4= s how long it takes for a scrub to complete in that system. So you=C2=B4ve = got to choose performance or savings, you can=C2=B4t have both.=20 <blockquote> And what about dedup of Netapp?=20 </blockquote> Much better implementation, in my opinion. You are able schedule dedup-runs= to go at night so your user=C2=B4s performance isn=C2=B4t impacted, and yo= u 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;)=20 /Karli=20 <blockquote> Jose=20 </blockquote> <blockquote> From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Quinta-feira, 30 de Maio de 2013 8:33:19=20 Subject: Re: [Users] deduplication=20 ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt :=20 <blockquote> Absolutely agree with you, planning is the best thing to do, but normally p= eople want a plug'n'play system with all included, because there is not muc= h time to think and planning, and there are many companies that know how to= take advantage of this people characteristics.=20 Any way, I think another solution for dedup is FreeNAS using ZFS.=20 </blockquote> FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it may increa= se performance when you have a very suitable usecase, e.g. everything exact= ly the same over and over. What=C2=B4s not said is that scrubbing and resil= vering slows down to a snail (from hundreds of MB/s, or GB if your system i= s large enough, down to less than 10), just from dedup. Also deleting snaps= hots 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... N= ow, compression on the other hand, you get basically for free and gives dec= ent savings, I highly recommend that.=20 /Karli=20 <blockquote> Jose=20 From: "Jiri Belka" < jbelka@redhat.com >=20 To: suporte@logicworks.pt=20 Cc: users@ovirt.org=20 Sent: Quarta-feira, 29 de Maio de 2013 7:33:10=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 14:29:05 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20
That's why I'm making this questions, to demystify some buzzwords around = here.=20 But if you have a strong and good technology why not create buzzwords to = get into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wh= ere I can start?=20
<div><br></div><div>We also have FreeNAS working in our infraestructure, w= ith about 3 TB and ZFS. Some of the pools has compression enabled and you c= an save space with it. We have this FreeNAS connected to a hypervisor Xen a= nd it works very well and it's stable and sure. We have nine virtual server= s some wirtualized and other paravirtualized, and some Windows Server machi= ne all about 2 years in production without any problem. My idea is connect =
Everything depends on your needs, design planning. Maybe then sharing=20 disk would be better to share via NFS/iscsi. Of course if you have many=20 VMs each of them is different you will fail. But if you have mostly=20 homogeneous environment you can think about this approach. Sure you have=20 to have plan for upgrading "base" "static" shared OS data, you have to=20 have plan how to install additional software (different destination=20 than /usr or /usr/local)... If you already have your own build host=20 which builds for you OS packages and you have already your own plan for=20 deployment, you have done first steps. If you depend on upgrading each=20 machine separately from Internet, then first you should plan your=20 environment, configuration management etc.=20 Well, in many times people do not do any planning, they just think some=20 good technology would save their "poor" design.=20 j.=20 </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 </blockquote> <blockquote> </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 </blockquote> _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 </blockquote> --=20 Chris Noffsinger=20 ------=_Part_1980_16023178.1370280384707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>If we have a hardware RAID controller will we need RAID-Z ?<br>= <br>Jose<br><br><hr id=3D"zwchr"><div style=3D"color: rgb(0, 0, 0); font-we= ight: normal; font-style: normal; text-decoration: none; font-family: Helve= tica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Chris Noffsinger" &l= t;cnoffsin@gmail.com><br><b>To: </b>suporte@logicworks.pt<br><b>Cc: </b>= "Juan Jose" <jj197005@gmail.com>, users@ovirt.org<br><b>Sent: </b>Seg= unda-feira, 3 de Junho de 2013 17:16:55<br><b>Subject: </b>Re: [Users] dedu= plication<br><br>Just wanted to add that Freenas is great. I use it w= ith NFS and ISCSI and it works well. What I will say, on the HP DNS-3= 20 I have in it I have had to go to the command prompt to fix some multipat= hing issues when I first add a disk but I beleive that is just a product of= the cciss controller driver in that server.<br> <br><div class=3D"gmail_quote">On Mon, Jun 3, 2013 at 12:12 PM, <span dir= =3D"ltr"><<a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">sup= orte@logicworks.pt</a>></span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,= 204); padding-left: 1ex;"> <div><div style=3D"font-size: 10pt; font-family: arial,helvetica,sans-serif= ;">Hi Juan,<br><br>thanks for your info, I'll try to test FreeNAS with comp= ression. Do you use it with iSCSI or NFS?<br><br>Jose<br><br><hr><div style= =3D"font-size: 12pt; font-style: normal; font-family: Helvetica,Arial,sans-= serif; text-decoration: none; font-weight: normal;"> <b>From: </b>"Juan Jose" <<a href=3D"mailto:jj197005@gmail.com" target= =3D"_blank">jj197005@gmail.com</a>><br><b>To: </b><a href=3D"mailto:supo= rte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</a>, <a href=3D"= mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a><br> <b>Sent: </b>Segunda-feira, 3 de Junho de 2013 13:37:21<br><b>Subject: </b>= Re: [Users] deduplication<br><br><div dir=3D"ltr"><br><div>Hello Jose,</div= this infrastructure with oVirt wo be able to have some resources for test V= Ms in that. Only wanted to share as another FreeNas success experience.</di= v> <div><br></div><div>Juanjo.</div></div><div class=3D"gmail_extra"><br><br><= div class=3D"gmail_quote">On Fri, May 31, 2013 at 12:33 PM, <span dir=3D"l= tr"><<a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@= logicworks.pt</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style= =3D"font-size: 10pt; font-family: arial,helvetica,sans-serif;">Thanks a lot= Karli, you make my mind clear about deduplication, once again we cannot ha= ve the best of both worlds.<br> <br>I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, runni= ng on Linux, has no better performance but supports DRDB.<br><br>Jose<br><b= r><hr><div style=3D"font-size: 12pt; font-style: normal; font-family: Helve= tica,Arial,sans-serif; text-decoration: none; font-weight: normal;"> <div><b>From: </b>"Karli Sj=C3=B6berg" <<a href=3D"mailto:Karli.Sjoberg@= slu.se" target=3D"_blank">Karli.Sjoberg@slu.se</a>><br><b>To: </b><a hre= f=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt<= /a><br> <b>Cc: </b>"Jiri Belka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"= _blank">jbelka@redhat.com</a>>, <a href=3D"mailto:users@ovirt.org" targe= t=3D"_blank">users@ovirt.org</a><br></div><b>Sent: </b>Sexta-feira, 31 de M= aio de 2013 10:45:41<br> <b>Subject: </b>Re: [Users] deduplication<div><div><br><br> fre 2013-05-31 klockan 09:50 +0100 skrev <a href=3D"mailto:suporte@logicwor= ks.pt" target=3D"_blank">suporte@logicworks.pt</a>: <blockquote><font color=3D"#000000">So, we can say that dedup has more disa= dvantages 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4s how long it takes for a scrub to c= omplete in that system. So you=C2=B4ve got to choose performance or savings, you can=C2=B4t have both.<br> <br> <blockquote><br> <font color=3D"#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=C2=B4s performance isn=C2=B4t impacted, and yo= u 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 H= DD's from anywhere... We did;)<br> <br> /Karli<br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <hr align=3D"center"> </blockquote> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Karli Sj=C3=B6berg" <<a href=3D"mailto:Karli.Sjoberg@slu.se" targe= t=3D"_blank">Karli.Sjoberg@slu.se</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">"Jiri Bel= ka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@redha= t.com</a>>, <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@o= virt.org</a></font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quinta-= feira, 30 de Maio de 2013 8:33:19</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">ons 2013-05-29 klockan 09:59 +0100 skrev <a href=3D= "mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</a>: </font><br> <blockquote><font color=3D"#000000">Absolutely agree with you, planning is = the best thing to do, but normally people want a plug'n'play system with al= l 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=3D"#000000">Any way, I think another solution for dedup is Free= NAS using ZFS.</font><br> </blockquote> <br> <font color=3D"#000000">FreeNAS is just FreeBSD with a fancy web-ui ontop, = so it=C2=B4s neither more or less of ZFS than you would have otherwise, And= regarding dedup in ZFS; Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s= said that it </font><font color=3D"#000000"><b>may</b></font><font color=3D"#000000"> in= crease performance when you have a very suitable usecase, e.g. everything </font><font color=3D"#000000"><b>exactly</b></font><font color=3D"#000000"=
the same over and over. What=C2=B4s not said is that scrubbing and resilv= ering 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) ded= up 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=3D"#000000">/Karli</font><br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <br> <hr align=3D"center"> <br> <b><font color=3D"#000000">From: </font></b><font color=3D"#000000">"Jiri B= elka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@red= hat.com</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000"><a href= =3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a></font><br=
<b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quarta-= feira, 29 de Maio de 2013 7:33:10</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br=
<font color=3D"#000000"><a href=3D"mailto:suporte@logicworks.pt" target=3D"= _blank">suporte@logicworks.pt</a> wrote:</font><br> <br> <font color=3D"#000000">> That's why I'm making this questions, to demys= tify some buzzwords around here.</font><br> <font color=3D"#000000">> But if you have a strong and good technology w= hy not create buzzwords to get into as many people as possible? without tra= pped them.</font><br> <font color=3D"#000000">> Share a disk containing "static" data is a goo= d idea, do you know from where I can start?</font><br> <br> <font color=3D"#000000">Everything depends on your needs, design planning. = Maybe then sharing</font><br> <font color=3D"#000000">disk would be better to share via NFS/iscsi. Of cou= rse if you have many</font><br> <font color=3D"#000000">VMs each of them is different you will fail. But if= you have mostly</font><br> <font color=3D"#000000">homogeneous environment you can think about this ap= proach. Sure you have</font><br> <font color=3D"#000000">to have plan for upgrading "base" "static" shared O= S data, you have to</font><br> <font color=3D"#000000">have plan how to install additional software (diffe= rent destination</font><br> <font color=3D"#000000">than /usr or /usr/local)... If you already have you= r own build host</font><br> <font color=3D"#000000">which builds for you OS packages and you have alrea= dy your own plan for</font><br> <font color=3D"#000000">deployment, you have done first steps. If you depen= d on upgrading each</font><br> <font color=3D"#000000">machine separately from Internet, then first you sh= ould plan your</font><br> <font color=3D"#000000">environment, configuration management etc.</font><b= r> <br> <font color=3D"#000000">Well, in many times people do not do any planning, = they just think some</font><br> <font color=3D"#000000">good technology would save their "poor" design.</fo= nt><br> <br> <font color=3D"#000000">j.</font><br> <br> <br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: <a href=3D"tel:%2B46-%280%2918-67%2015%2066" target=3D"_blank"=
+46-(0)18-67 15 66</a><br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </blockquote> <blockquote><br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: <a href=3D"tel:%2B46-%280%2918-67%2015%2066" target=3D"_blank"= +46-(0)18-67 15 66</a><br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </div></div></div><br></div></div><br>_____________________________________= __________<br> Users mailing list<br> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.org</a><br=
<a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"=
http://lists.ovirt.org/mailman/listinfo/users</a><br> <br></blockquote></div><br></div> </div><br></div></div><br>_______________________________________________<b= r> Users mailing list<br> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.org</a><br=
<a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"=
http://lists.ovirt.org/mailman/listinfo/users</a><br> <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Chris No= ffsinger<br> </div><br></div></body></html> ------=_Part_1980_16023178.1370280384707--
--_000_5F9E965F5A80BC468BE5F40576769F092E650438exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 bcOlbiAyMDEzLTA2LTAzIGtsb2NrYW4gMTg6MjYgKzAxMDAgc2tyZXYgc3Vwb3J0ZUBsb2dpY3dv cmtzLnB0Og0KSWYgd2UgaGF2ZSBhIGhhcmR3YXJlIFJBSUQgY29udHJvbGxlciB3aWxsIHdlIG5l ZWQgUkFJRC1aID8NCg0KRmluZCBhIHdheSBvZiB0dXJuaW5nIHRoYXQgZmFuY3kgUkFJRCBjb250 cm9sbGVyIGludG8ganVzdCBhICJidW1iIiBIQkEgYW5kIHNlbmQgYWxsIG9mIGRpc2tzIGFzIEpC T0QgdG8gdGhlIE9TLiBaRlMgaXMgZGVzaWduZWQgZm9yIHRoYXQgcHVycG9zZS4gSWYgeW91IGNh bsK0dCBkbyB0aGF0LCBidXkgYSBjaGVhcCBTQVMgY29udHJvbGxlciBpbnN0ZWFkLCBhbHRlcm5h dGl2ZWx5IG1ha2UgUkFJRDAgdm9sdW1lcyBmb3IgZWFjaCBkaXNrIGNvbm5lY3RlZCB0byB0aGUg UkFJRCBjb250cm9sbGVyLCBidXQgScK0dmUgaGFkIGlzc3VlcyB3aXRoIGRpc2tzIGR5aW5nIHRo YXQgbmVlZHMgdGhlIG1hY2hpbmUgdG8gcmVib290IGZvciBpdCB0byByZWFsaXplIHRoYXQgeW91 wrR2ZSByZXBsYWNlZCB0aGUgZGlzay4gRXNwZWNpYWxseSBIUCBzZXJ2ZXJzIGFyZSB0aGUgb25l wrRzIGNvbnRyb2xsZXJzIHRoYXTCtHMgYmVlbiBsaWtlIHRoYXQuDQoNCi9LYXJsaQ0KDQoNCkpv c2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206ICJDaHJpcyBOb2Zm c2luZ2VyIiA8Y25vZmZzaW5AZ21haWwuY29tPg0KVG86IHN1cG9ydGVAbG9naWN3b3Jrcy5wdA0K Q2M6ICJKdWFuIEpvc2UiIDxqajE5NzAwNUBnbWFpbC5jb20+LCB1c2Vyc0BvdmlydC5vcmcNClNl bnQ6IFNlZ3VuZGEtZmVpcmEsIDMgZGUgSnVuaG8gZGUgMjAxMyAxNzoxNjo1NQ0KU3ViamVjdDog UmU6IFtVc2Vyc10gZGVkdXBsaWNhdGlvbg0KDQpKdXN0IHdhbnRlZCB0byBhZGQgdGhhdCBGcmVl bmFzIGlzIGdyZWF0LiAgSSB1c2UgaXQgd2l0aCBORlMgYW5kIElTQ1NJIGFuZCBpdCB3b3JrcyB3 ZWxsLiAgV2hhdCBJIHdpbGwgc2F5LCBvbiB0aGUgSFAgRE5TLTMyMCBJIGhhdmUgaW4gaXQgSSBo YXZlIGhhZCB0byBnbyB0byB0aGUgY29tbWFuZCBwcm9tcHQgdG8gZml4IHNvbWUgbXVsdGlwYXRo aW5nIGlzc3VlcyB3aGVuIEkgZmlyc3QgYWRkIGEgZGlzayBidXQgSSBiZWxlaXZlIHRoYXQgaXMg anVzdCBhIHByb2R1Y3Qgb2YgdGhlIGNjaXNzIGNvbnRyb2xsZXIgZHJpdmVyIGluIHRoYXQgc2Vy dmVyLg0KDQpPbiBNb24sIEp1biAzLCAyMDEzIGF0IDEyOjEyIFBNLCA8c3Vwb3J0ZUBsb2dpY3dv cmtzLnB0PG1haWx0bzpzdXBvcnRlQGxvZ2ljd29ya3MucHQ+PiB3cm90ZToNCkhpIEp1YW4sDQoN CnRoYW5rcyBmb3IgeW91ciBpbmZvLCBJJ2xsIHRyeSB0byB0ZXN0IEZyZWVOQVMgd2l0aCBjb21w cmVzc2lvbi4gRG8geW91IHVzZSBpdCB3aXRoIGlTQ1NJIG9yIE5GUz8NCg0KSm9zZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogIkp1YW4gSm9zZSIgPGpqMTk3MDA1 QGdtYWlsLmNvbTxtYWlsdG86amoxOTcwMDVAZ21haWwuY29tPj4NClRvOiBzdXBvcnRlQGxvZ2lj d29ya3MucHQ8bWFpbHRvOnN1cG9ydGVAbG9naWN3b3Jrcy5wdD4sIHVzZXJzQG92aXJ0Lm9yZzxt YWlsdG86dXNlcnNAb3ZpcnQub3JnPg0KU2VudDogU2VndW5kYS1mZWlyYSwgMyBkZSBKdW5obyBk ZSAyMDEzIDEzOjM3OjIxDQpTdWJqZWN0OiBSZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uDQoNCg0K SGVsbG8gSm9zZSwNCg0KDQpXZSBhbHNvIGhhdmUgRnJlZU5BUyB3b3JraW5nIGluIG91ciBpbmZy YWVzdHJ1Y3R1cmUsIHdpdGggYWJvdXQgMyBUQiBhbmQgWkZTLiBTb21lIG9mIHRoZSBwb29scyBo YXMgY29tcHJlc3Npb24gZW5hYmxlZCBhbmQgeW91IGNhbiBzYXZlIHNwYWNlIHdpdGggaXQuIFdl IGhhdmUgdGhpcyBGcmVlTkFTIGNvbm5lY3RlZCB0byBhIGh5cGVydmlzb3IgWGVuIGFuZCBpdCB3 b3JrcyB2ZXJ5IHdlbGwgYW5kIGl0J3Mgc3RhYmxlIGFuZCBzdXJlLiBXZSBoYXZlIG5pbmUgdmly dHVhbCBzZXJ2ZXJzIHNvbWUgd2lydHVhbGl6ZWQgYW5kIG90aGVyIHBhcmF2aXJ0dWFsaXplZCwg YW5kIHNvbWUgV2luZG93cyBTZXJ2ZXIgbWFjaGluZSBhbGwgYWJvdXQgMiB5ZWFycyBpbiBwcm9k dWN0aW9uIHdpdGhvdXQgYW55IHByb2JsZW0uIE15IGlkZWEgaXMgY29ubmVjdCB0aGlzIGluZnJh c3RydWN0dXJlIHdpdGggb1ZpcnQgd28gYmUgYWJsZSB0byBoYXZlIHNvbWUgcmVzb3VyY2VzIGZv ciB0ZXN0IFZNcyBpbiB0aGF0LiBPbmx5IHdhbnRlZCB0byBzaGFyZSBhcyBhbm90aGVyIEZyZWVO YXMgc3VjY2VzcyBleHBlcmllbmNlLg0KDQoNCkp1YW5qby4NCg0KDQpPbiBGcmksIE1heSAzMSwg MjAxMyBhdCAxMjozMyBQTSwgPHN1cG9ydGVAbG9naWN3b3Jrcy5wdDxtYWlsdG86c3Vwb3J0ZUBs b2dpY3dvcmtzLnB0Pj4gd3JvdGU6DQpUaGFua3MgYSBsb3QgS2FybGksIHlvdSBtYWtlIG15IG1p bmQgY2xlYXIgYWJvdXQgZGVkdXBsaWNhdGlvbiwgb25jZSBhZ2FpbiB3ZSBjYW5ub3QgaGF2ZSB0 aGUgYmVzdCBvZiBib3RoIHdvcmxkcy4NCg0KSSdsbCB0cnkgRnJlZU5BUyBkZXNwaXRlIG15IHBv b3Iga25vd2xlZGdlIG9uIEZyZWVCU0QuIE9wZW5maWxlciwgcnVubmluZyBvbiBMaW51eCwgaGFz IG5vIGJldHRlciBwZXJmb3JtYW5jZSBidXQgc3VwcG9ydHMgRFJEQi4NCg0KSm9zZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogIkthcmxpIFNqw7ZiZXJnIiA8S2Fy bGkuU2pvYmVyZ0BzbHUuc2U8bWFpbHRvOkthcmxpLlNqb2JlcmdAc2x1LnNlPj4NClRvOiBzdXBv cnRlQGxvZ2ljd29ya3MucHQ8bWFpbHRvOnN1cG9ydGVAbG9naWN3b3Jrcy5wdD4NCkNjOiAiSmly aSBCZWxrYSIgPGpiZWxrYUByZWRoYXQuY29tPG1haWx0bzpqYmVsa2FAcmVkaGF0LmNvbT4+LCB1 c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4NCg0KU2VudDogU2V4dGEtZmVp cmEsIDMxIGRlIE1haW8gZGUgMjAxMyAxMDo0NTo0MQ0KU3ViamVjdDogUmU6IFtVc2Vyc10gZGVk dXBsaWNhdGlvbg0KDQoNCmZyZSAyMDEzLTA1LTMxIGtsb2NrYW4gMDk6NTAgKzAxMDAgc2tyZXYg c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PG1haWx0bzpzdXBvcnRlQGxvZ2ljd29ya3MucHQ+Og0KU28s IHdlIGNhbiBzYXkgdGhhdCBkZWR1cCBoYXMgbW9yZSBkaXNhZHZhbnRhZ2VzIHRoYW4gYWR2YW50 YWdlcy4NCg0KRm9yIGEgcHJpbWFyeSBzeXN0ZW07IG1vc3QgZGVmaW5pdGVseSwgeWVzLg0KDQpC dXQgZm9yIGEgYmFja3VwIHN5c3RlbSwgdGhhdCBoYXMgdG9ucyBvZiBSQU0gYW5kIFNTRCdzIGZv ciBjYWNoZSwgYW5kIHlvdSBoYXZlIGxvdHMgb2YgdmlydHVhbCBtYWNoaW5lcyB0aGF0IGFyZSBi YXNlZCBvZmYgb2YgdGhlIHRlbXBsYXRlLCBvciBhcmUgdmVyeSBtdWNoIHRoZSBzYW1lLCB0aGVu IHlvdSBoYXZlIGEgcmVhbCB1c2UtY2FzZS4gScK0bSBhY3RpdmUgYXQgdGhlIEZyZWVCU0QgZm9y dW1zIHdoZXJlIG9uZSBwZXJzb24gcmVwb3J0cyBzdG9yaW5nIDE1MFRCIG9mIGRhdGEgaW4gb25s eSAzMFRCIG9mIHBoeXNpY2FsIGRpc2suIFRoZSBiZXN0IHByYWN0aWNlIG9mIHNjcnViYmluZyBp cyBvbmNlIGEgd2VlayBvbiAiZW50ZXJwcmlzZSIgc3lzdGVtcywgdGhvdWdoIGhlIGlzIG9ubHkg YWJsZSB0byBkbyBpdCBvbmNlIGEgbW9udGgsIGJlY2F1c2UgdGhhdMK0cyBob3cgbG9uZyBpdCB0 YWtlcyBmb3IgYSBzY3J1YiB0byBjb21wbGV0ZSBpbiB0aGF0IHN5c3RlbS4gU28geW91wrR2ZSBn b3QgdG8gY2hvb3NlIHBlcmZvcm1hbmNlIG9yIHNhdmluZ3MsIHlvdSBjYW7CtHQgaGF2ZSBib3Ro Lg0KDQoNCkFuZCB3aGF0IGFib3V0IGRlZHVwIG9mIE5ldGFwcD8NCg0KTXVjaCBiZXR0ZXIgaW1w bGVtZW50YXRpb24sIGluIG15IG9waW5pb24uIFlvdSBhcmUgYWJsZSBzY2hlZHVsZSBkZWR1cC1y dW5zIHRvIGdvIGF0IG5pZ2h0IHNvIHlvdXIgdXNlcsK0cyBwZXJmb3JtYW5jZSBpc27CtHQgaW1w YWN0ZWQsIGFuZCB5b3UgZ2V0IHRoZSBzYXZpbmdzLiBUaGUgcXVlc3Rpb24gaXMgaWYgeW91IHZh bHVlIHRoZSBzYXZpbmdzIGVub3VnaCB0byB0YWtlIG9uIHByaWNlLXRhZyB0aGF0IGlzIE5ldEFw cC4gT3IganVzdCBidWlsZCB5b3VyIG93biBGcmVlQlNEL1pGUyBzZXJ2ZXIgd2l0aCBjb21wcmVz c2lvbiBlbmFibGVkIGFuZCBidXkgaW4gc3RhbmRhcmQgSEREJ3MgZnJvbSBhbnl3aGVyZS4uLiBX ZSBkaWQ7KQ0KDQovS2FybGkNCg0KDQpKb3NlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkZyb206ICJLYXJsaSBTasO2YmVyZyIgPEthcmxpLlNqb2JlcmdAc2x1LnNlPG1h aWx0bzpLYXJsaS5Tam9iZXJnQHNsdS5zZT4+DQpUbzogc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PG1h aWx0bzpzdXBvcnRlQGxvZ2ljd29ya3MucHQ+DQpDYzogIkppcmkgQmVsa2EiIDxqYmVsa2FAcmVk aGF0LmNvbTxtYWlsdG86amJlbGthQHJlZGhhdC5jb20+PiwgdXNlcnNAb3ZpcnQub3JnPG1haWx0 bzp1c2Vyc0BvdmlydC5vcmc+DQpTZW50OiBRdWludGEtZmVpcmEsIDMwIGRlIE1haW8gZGUgMjAx MyA4OjMzOjE5DQpTdWJqZWN0OiBSZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uDQoNCm9ucyAyMDEz LTA1LTI5IGtsb2NrYW4gMDk6NTkgKzAxMDAgc2tyZXYgc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PG1h aWx0bzpzdXBvcnRlQGxvZ2ljd29ya3MucHQ+Og0KQWJzb2x1dGVseSBhZ3JlZSB3aXRoIHlvdSwg cGxhbm5pbmcgaXMgdGhlIGJlc3QgdGhpbmcgdG8gZG8sIGJ1dCBub3JtYWxseSBwZW9wbGUgd2Fu dCBhIHBsdWcnbidwbGF5IHN5c3RlbSB3aXRoIGFsbCBpbmNsdWRlZCwgYmVjYXVzZSB0aGVyZSBp cyBub3QgbXVjaCB0aW1lIHRvIHRoaW5rIGFuZCBwbGFubmluZywgYW5kIHRoZXJlIGFyZSBtYW55 IGNvbXBhbmllcyB0aGF0IGtub3cgaG93IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgcGVvcGxl IGNoYXJhY3RlcmlzdGljcy4NCkFueSB3YXksIEkgdGhpbmsgYW5vdGhlciBzb2x1dGlvbiBmb3Ig ZGVkdXAgaXMgRnJlZU5BUyB1c2luZyBaRlMuDQoNCkZyZWVOQVMgaXMganVzdCBGcmVlQlNEIHdp dGggYSBmYW5jeSB3ZWItdWkgb250b3AsIHNvIGl0wrRzIG5laXRoZXIgbW9yZSBvciBsZXNzIG9m IFpGUyB0aGFuIHlvdSB3b3VsZCBoYXZlIG90aGVyd2lzZSwgQW5kIHJlZ2FyZGluZyBkZWR1cCBp biBaRlM7IEp1c3QgZG9uwrR0LCBpdMK0cyBub3Qgd29ydGggaXQhIEl0wrRzIHNhaWQgdGhhdCBp dG1heSBpbmNyZWFzZSBwZXJmb3JtYW5jZSB3aGVuIHlvdSBoYXZlIGEgdmVyeSBzdWl0YWJsZSB1 c2VjYXNlLCBlLmcuIGV2ZXJ5dGhpbmdleGFjdGx5IHRoZSBzYW1lIG92ZXIgYW5kIG92ZXIuIFdo YXTCtHMgbm90IHNhaWQgaXMgdGhhdCBzY3J1YmJpbmcgYW5kIHJlc2lsdmVyaW5nIHNsb3dzIGRv d24gdG8gYSBzbmFpbCAoZnJvbSBodW5kcmVkcyBvZiBNQi9zLCBvciBHQiBpZiB5b3VyIHN5c3Rl bSBpcyBsYXJnZSBlbm91Z2gsIGRvd24gdG8gbGVzcyB0aGFuIDEwKSwganVzdCBmcm9tIGRlZHVw LiBBbHNvIGRlbGV0aW5nIHNuYXBzaG90cyBvZiBkYXRhc2V0cyB0aGF0IGhhdmUob3IgaGF2ZSBo YWQpIGRlZHVwIG9uIGNhbiBraWxsIHRoZSBlbnRpcmUgc3lzdGVtLCBhbmQgd2hlbiBJIHNheSBr aWxsLCBJIG1lYW4gcmVhbGx5IGZ1YmFyLiBCZWVuIHRoZXJlLCByZWdyZXR0ZWQgdGhhdC4uLiBO b3csIGNvbXByZXNzaW9uIG9uIHRoZSBvdGhlciBoYW5kLCB5b3UgZ2V0IGJhc2ljYWxseSBmb3Ig ZnJlZSBhbmQgZ2l2ZXMgZGVjZW50IHNhdmluZ3MsIEkgaGlnaGx5IHJlY29tbWVuZCB0aGF0Lg0K DQovS2FybGkNCg0KDQpKb3NlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQpGcm9tOiAiSmlyaSBCZWxrYSIgPGpiZWxrYUByZWRoYXQuY29tPG1haWx0bzpqYmVsa2FA cmVkaGF0LmNvbT4+DQpUbzogc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PG1haWx0bzpzdXBvcnRlQGxv Z2ljd29ya3MucHQ+DQpDYzogdXNlcnNAb3ZpcnQub3JnPG1haWx0bzp1c2Vyc0BvdmlydC5vcmc+ DQpTZW50OiBRdWFydGEtZmVpcmEsIDI5IGRlIE1haW8gZGUgMjAxMyA3OjMzOjEwDQpTdWJqZWN0 OiBSZTogW1VzZXJzXSBkZWR1cGxpY2F0aW9uDQoNCk9uIFR1ZSwgMjggTWF5IDIwMTMgMTQ6Mjk6 MDUgKzAxMDAgKFdFU1QpDQpzdXBvcnRlQGxvZ2ljd29ya3MucHQ8bWFpbHRvOnN1cG9ydGVAbG9n aWN3b3Jrcy5wdD4gd3JvdGU6DQoNCj4gVGhhdCdzIHdoeSBJJ20gbWFraW5nIHRoaXMgcXVlc3Rp b25zLCB0byBkZW15c3RpZnkgc29tZSBidXp6d29yZHMgYXJvdW5kIGhlcmUuDQo+IEJ1dCBpZiB5 b3UgaGF2ZSBhIHN0cm9uZyBhbmQgZ29vZCB0ZWNobm9sb2d5IHdoeSBub3QgY3JlYXRlIGJ1enp3 b3JkcyB0byBnZXQgaW50byBhcyBtYW55IHBlb3BsZSBhcyBwb3NzaWJsZT8gd2l0aG91dCB0cmFw cGVkIHRoZW0uDQo+IFNoYXJlIGEgZGlzayBjb250YWluaW5nICJzdGF0aWMiIGRhdGEgaXMgYSBn b29kIGlkZWEsIGRvIHlvdSBrbm93IGZyb20gd2hlcmUgSSBjYW4gc3RhcnQ/DQoNCkV2ZXJ5dGhp bmcgZGVwZW5kcyBvbiB5b3VyIG5lZWRzLCBkZXNpZ24gcGxhbm5pbmcuIE1heWJlIHRoZW4gc2hh cmluZw0KZGlzayB3b3VsZCBiZSBiZXR0ZXIgdG8gc2hhcmUgdmlhIE5GUy9pc2NzaS4gT2YgY291 cnNlIGlmIHlvdSBoYXZlIG1hbnkNClZNcyBlYWNoIG9mIHRoZW0gaXMgZGlmZmVyZW50IHlvdSB3 aWxsIGZhaWwuIEJ1dCBpZiB5b3UgaGF2ZSBtb3N0bHkNCmhvbW9nZW5lb3VzIGVudmlyb25tZW50 IHlvdSBjYW4gdGhpbmsgYWJvdXQgdGhpcyBhcHByb2FjaC4gU3VyZSB5b3UgaGF2ZQ0KdG8gaGF2 ZSBwbGFuIGZvciB1cGdyYWRpbmcgImJhc2UiICJzdGF0aWMiIHNoYXJlZCBPUyBkYXRhLCB5b3Ug aGF2ZSB0bw0KaGF2ZSBwbGFuIGhvdyB0byBpbnN0YWxsIGFkZGl0aW9uYWwgc29mdHdhcmUgKGRp ZmZlcmVudCBkZXN0aW5hdGlvbg0KdGhhbiAvdXNyIG9yIC91c3IvbG9jYWwpLi4uIElmIHlvdSBh bHJlYWR5IGhhdmUgeW91ciBvd24gYnVpbGQgaG9zdA0Kd2hpY2ggYnVpbGRzIGZvciB5b3UgT1Mg cGFja2FnZXMgYW5kIHlvdSBoYXZlIGFscmVhZHkgeW91ciBvd24gcGxhbiBmb3INCmRlcGxveW1l bnQsIHlvdSBoYXZlIGRvbmUgZmlyc3Qgc3RlcHMuIElmIHlvdSBkZXBlbmQgb24gdXBncmFkaW5n IGVhY2gNCm1hY2hpbmUgc2VwYXJhdGVseSBmcm9tIEludGVybmV0LCB0aGVuIGZpcnN0IHlvdSBz aG91bGQgcGxhbiB5b3VyDQplbnZpcm9ubWVudCwgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGV0 Yy4NCg0KV2VsbCwgaW4gbWFueSB0aW1lcyBwZW9wbGUgZG8gbm90IGRvIGFueSBwbGFubmluZywg dGhleSBqdXN0IHRoaW5rIHNvbWUNCmdvb2QgdGVjaG5vbG9neSB3b3VsZCBzYXZlIHRoZWlyICJw b29yIiBkZXNpZ24uDQoNCmouDQoNCg0KDQoNCi0tDQoNCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdh cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KS2FybGkgU2rDtmJlcmcNClN3ZWRpc2ggVW5pdmVy c2l0eSBvZiBBZ3JpY3VsdHVyYWwgU2NpZW5jZXMNCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNz IEtyb27DpXN2w6RnZW4gOCkNClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRlbg0KUGhvbmU6ICArNDYt KDApMTgtNjcgMTUgNjY8dGVsOiUyQjQ2LSUyODAlMjkxOC02NyUyMDE1JTIwNjY+DQprYXJsaS5z am9iZXJnQHNsdS5zZTxtYWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlPg0KDQoNCg0KLS0N Cg0KTWVkIFbDpG5saWdhIEjDpGxzbmluZ2FyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLYXJs aSBTasO2YmVyZw0KU3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlcw0K Qm94IDcwNzkgKFZpc2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KQ0KUy03NTAgMDcgVXBw c2FsYSwgU3dlZGVuDQpQaG9uZTogICs0Ni0oMCkxOC02NyAxNSA2Njx0ZWw6JTJCNDYtJTI4MCUy OTE4LTY3JTIwMTUlMjA2Nj4NCmthcmxpLnNqb2JlcmdAc2x1LnNlPG1haWx0bzprYXJsaS5zam9i ZXJnQGFkbS5zbHUuc2U+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVXNlcnMgbWFpbGluZyBsaXN0DQpVc2Vyc0BvdmlydC5vcmc8bWFpbHRv OlVzZXJzQG92aXJ0Lm9yZz4NCmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5m by91c2Vycw0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClVzZXJzIG1haWxpbmcgbGlzdA0KVXNlcnNAb3ZpcnQub3JnPG1haWx0bzpV c2Vyc0BvdmlydC5vcmc+DQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8v dXNlcnMNCg0KDQoNCg0KDQotLQ0KQ2hyaXMgTm9mZnNpbmdlcg0KDQoNCg0KDQotLQ0KDQpNZWQg VsOkbmxpZ2EgSMOkbHNuaW5nYXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkthcmxpIFNqw7Zi ZXJnDQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzDQpCb3ggNzA3 OSAoVmlzaXRpbmcgQWRkcmVzcyBLcm9uw6VzdsOkZ2VuIDgpDQpTLTc1MCAwNyBVcHBzYWxhLCBT d2VkZW4NClBob25lOiAgKzQ2LSgwKTE4LTY3IDE1IDY2DQprYXJsaS5zam9iZXJnQHNsdS5zZTxt YWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlPg0K --_000_5F9E965F5A80BC468BE5F40576769F092E650438exchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQptw6VuIDIwMTMtMDYt MDMga2xvY2thbiAxODoyNiAmIzQzOzAxMDAgc2tyZXYgc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0Og0K PGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPklmIHdlIGhhdmUg YSBoYXJkd2FyZSBSQUlEIGNvbnRyb2xsZXIgd2lsbCB3ZSBuZWVkIFJBSUQtWiA/PC9mb250Pjxi cj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCkZpbmQgYSB3YXkgb2YgdHVybmluZyB0aGF0IGZhbmN5 IFJBSUQgY29udHJvbGxlciBpbnRvIGp1c3QgYSAmcXVvdDtidW1iJnF1b3Q7IEhCQSBhbmQgc2Vu ZCBhbGwgb2YgZGlza3MgYXMgSkJPRCB0byB0aGUgT1MuIFpGUyBpcyBkZXNpZ25lZCBmb3IgdGhh dCBwdXJwb3NlLiBJZiB5b3UgY2FuwrR0IGRvIHRoYXQsIGJ1eSBhIGNoZWFwIFNBUyBjb250cm9s bGVyIGluc3RlYWQsIGFsdGVybmF0aXZlbHkgbWFrZSBSQUlEMCB2b2x1bWVzIGZvciBlYWNoIGRp c2sgY29ubmVjdGVkDQogdG8gdGhlIFJBSUQgY29udHJvbGxlciwgYnV0IEnCtHZlIGhhZCBpc3N1 ZXMgd2l0aCBkaXNrcyBkeWluZyB0aGF0IG5lZWRzIHRoZSBtYWNoaW5lIHRvIHJlYm9vdCBmb3Ig aXQgdG8gcmVhbGl6ZSB0aGF0IHlvdcK0dmUgcmVwbGFjZWQgdGhlIGRpc2suIEVzcGVjaWFsbHkg SFAgc2VydmVycyBhcmUgdGhlIG9uZcK0cyBjb250cm9sbGVycyB0aGF0wrRzIGJlZW4gbGlrZSB0 aGF0Ljxicj4NCjxicj4NCi9LYXJsaTxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUi Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5Kb3NlPC9mb250Pjxicj4NCjxicj4NCjxociBh bGlnbj0iY2VudGVyIj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPjxi Pjxmb250IGNvbG9yPSIjMDAwMDAwIj5Gcm9tOiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAw MDAwIj4mcXVvdDtDaHJpcyBOb2Zmc2luZ2VyJnF1b3Q7ICZsdDtjbm9mZnNpbkBnbWFpbC5jb20m Z3Q7PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5UbzogPC9mb250PjwvYj48 Zm9udCBjb2xvcj0iIzAwMDAwMCI+c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PC9mb250Pjxicj4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDAwIj5DYzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAw MCI+JnF1b3Q7SnVhbiBKb3NlJnF1b3Q7ICZsdDtqajE5NzAwNUBnbWFpbC5jb20mZ3Q7LCB1c2Vy c0BvdmlydC5vcmc8L2ZvbnQ+PGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlNlbnQ6IDwv Zm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlNlZ3VuZGEtZmVpcmEsIDMgZGUgSnVuaG8g ZGUgMjAxMyAxNzoxNjo1NTwvZm9udD48YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+U3Vi amVjdDogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+UmU6IFtVc2Vyc10gZGVkdXBs aWNhdGlvbjwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+SnVzdCB3YW50 ZWQgdG8gYWRkIHRoYXQgRnJlZW5hcyBpcyBncmVhdC4gJm5ic3A7SSB1c2UgaXQgd2l0aCBORlMg YW5kIElTQ1NJIGFuZCBpdCB3b3JrcyB3ZWxsLiAmbmJzcDtXaGF0IEkgd2lsbCBzYXksIG9uIHRo ZSBIUCBETlMtMzIwIEkgaGF2ZSBpbiBpdCBJIGhhdmUgaGFkIHRvIGdvIHRvIHRoZSBjb21tYW5k IHByb21wdCB0byBmaXggc29tZSBtdWx0aXBhdGhpbmcgaXNzdWVzIHdoZW4gSSBmaXJzdCBhZGQg YSBkaXNrIGJ1dA0KIEkgYmVsZWl2ZSB0aGF0IGlzIGp1c3QgYSBwcm9kdWN0IG9mIHRoZSBjY2lz cyBjb250cm9sbGVyIGRyaXZlciBpbiB0aGF0IHNlcnZlci48L2ZvbnQ+PGJyPg0KPGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+PGZvbnQgY29sb3I9IiMwMDAwMDAi Pk9uIE1vbiwgSnVuIDMsIDIwMTMgYXQgMTI6MTIgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86c3Vw b3J0ZUBsb2dpY3dvcmtzLnB0Ij5zdXBvcnRlQGxvZ2ljd29ya3MucHQ8L2E+Jmd0OyB3cm90ZTo8 L2ZvbnQ+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1 b3RlPjxmb250IGNvbG9yPSIjMDAwMDAwIj5IaSBKdWFuLDwvZm9udD48YnI+DQo8YnI+DQo8Zm9u dCBjb2xvcj0iIzAwMDAwMCI+dGhhbmtzIGZvciB5b3VyIGluZm8sIEknbGwgdHJ5IHRvIHRlc3Qg RnJlZU5BUyB3aXRoIGNvbXByZXNzaW9uLiBEbyB5b3UgdXNlIGl0IHdpdGggaVNDU0kgb3IgTkZT PzwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Sm9zZTwvZm9udD48YnI+ DQo8YnI+DQo8aHIgYWxpZ249ImNlbnRlciI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPjxiPjxmb250IGNvbG9yPSIj MDAwMDAwIj5Gcm9tOiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAwIj4mcXVvdDtKdWFu IEpvc2UmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqajE5NzAwNUBnbWFpbC5jb20iPmpqMTk3 MDA1QGdtYWlsLmNvbTwvYT4mZ3Q7PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAw Ij5UbzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGEgaHJlZj0ibWFpbHRvOnN1 cG9ydGVAbG9naWN3b3Jrcy5wdCI+c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PC9hPiwNCjxhIGhyZWY9 Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT48L2ZvbnQ+PGJyPg0K PGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlNlbnQ6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMw MDAwMDAiPlNlZ3VuZGEtZmVpcmEsIDMgZGUgSnVuaG8gZGUgMjAxMyAxMzozNzoyMTwvZm9udD48 YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+U3ViamVjdDogPC9mb250PjwvYj48Zm9udCBj b2xvcj0iIzAwMDAwMCI+UmU6IFtVc2Vyc10gZGVkdXBsaWNhdGlvbjwvZm9udD48YnI+DQo8YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4N CjxibG9ja3F1b3RlPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+PGZvbnQgY29sb3I9IiMwMDAwMDAiPkhlbGxv IEpvc2UsPC9mb250PiA8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+PGZvbnQgY29s b3I9IiMwMDAwMDAiPldlIGFsc28gaGF2ZSBGcmVlTkFTIHdvcmtpbmcgaW4gb3VyIGluZnJhZXN0 cnVjdHVyZSwgd2l0aCBhYm91dCAzIFRCIGFuZCBaRlMuIFNvbWUgb2YgdGhlIHBvb2xzIGhhcyBj b21wcmVzc2lvbiBlbmFibGVkIGFuZCB5b3UgY2FuIHNhdmUgc3BhY2Ugd2l0aCBpdC4gV2UgaGF2 ZSB0aGlzIEZyZWVOQVMgY29ubmVjdGVkIHRvIGEgaHlwZXJ2aXNvciBYZW4gYW5kIGl0IHdvcmtz IHZlcnkgd2VsbA0KIGFuZCBpdCdzIHN0YWJsZSBhbmQgc3VyZS4gV2UgaGF2ZSBuaW5lIHZpcnR1 YWwgc2VydmVycyBzb21lIHdpcnR1YWxpemVkIGFuZCBvdGhlciBwYXJhdmlydHVhbGl6ZWQsIGFu ZCBzb21lIFdpbmRvd3MgU2VydmVyIG1hY2hpbmUgYWxsIGFib3V0IDIgeWVhcnMgaW4gcHJvZHVj dGlvbiB3aXRob3V0IGFueSBwcm9ibGVtLiBNeSBpZGVhIGlzIGNvbm5lY3QgdGhpcyBpbmZyYXN0 cnVjdHVyZSB3aXRoIG9WaXJ0IHdvIGJlIGFibGUgdG8gaGF2ZSBzb21lDQogcmVzb3VyY2VzIGZv ciB0ZXN0IFZNcyBpbiB0aGF0LiBPbmx5IHdhbnRlZCB0byBzaGFyZSBhcyBhbm90aGVyIEZyZWVO YXMgc3VjY2VzcyBleHBlcmllbmNlLjwvZm9udD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+PGJyPg0KPGJyPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8Ymxv Y2txdW90ZT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+SnVhbmpvLjwvZm9udD4gPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8YmxvY2txdW90ZT48 YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJDSVRFIj4NCjxibG9ja3F1b3RlPjxmb250IGNvbG9yPSIjMDAwMDAwIj5PbiBGcmksIE1heSAz MSwgMjAxMyBhdCAxMjozMyBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBvcnRlQGxvZ2ljd29y a3MucHQiPnN1cG9ydGVAbG9naWN3b3Jrcy5wdDwvYT4mZ3Q7IHdyb3RlOjwvZm9udD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+VGhhbmtzIGEgbG90IEth cmxpLCB5b3UgbWFrZSBteSBtaW5kIGNsZWFyIGFib3V0IGRlZHVwbGljYXRpb24sIG9uY2UgYWdh aW4gd2UgY2Fubm90IGhhdmUgdGhlIGJlc3Qgb2YgYm90aCB3b3JsZHMuPC9mb250Pjxicj4NCjxi cj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5JJ2xsIHRyeSBGcmVlTkFTIGRlc3BpdGUgbXkgcG9v ciBrbm93bGVkZ2Ugb24gRnJlZUJTRC4gT3BlbmZpbGVyLCBydW5uaW5nIG9uIExpbnV4LCBoYXMg bm8gYmV0dGVyIHBlcmZvcm1hbmNlIGJ1dCBzdXBwb3J0cyBEUkRCLjwvZm9udD48YnI+DQo8YnI+ DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Sm9zZTwvZm9udD48YnI+DQo8YnI+DQo8aHIgYWxpZ249 ImNlbnRlciI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGU+PGI+PGZv bnQgY29sb3I9IiMwMDAwMDAiPkZyb206IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAi PiZxdW90O0thcmxpIFNqw7ZiZXJnJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86S2FybGkuU2pv YmVyZ0BzbHUuc2UiPkthcmxpLlNqb2JlcmdAc2x1LnNlPC9hPiZndDs8L2ZvbnQ+PGJyPg0KPGI+ PGZvbnQgY29sb3I9IiMwMDAwMDAiPlRvOiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAw Ij48YSBocmVmPSJtYWlsdG86c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0Ij5zdXBvcnRlQGxvZ2ljd29y a3MucHQ8L2E+PC9mb250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5DYzogPC9mb250 PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+JnF1b3Q7SmlyaSBCZWxrYSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpiZWxrYUByZWRoYXQuY29tIj5qYmVsa2FAcmVkaGF0LmNvbTwvYT4mZ3Q7 LA0KPGEgaHJlZj0ibWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9hPjwv Zm9udD48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGU+ PGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlNlbnQ6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMw MDAwMDAiPlNleHRhLWZlaXJhLCAzMSBkZSBNYWlvIGRlIDIwMTMgMTA6NDU6NDE8L2ZvbnQ+PGJy Pg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlN1YmplY3Q6IDwvZm9udD48L2I+PGZvbnQgY29s b3I9IiMwMDAwMDAiPlJlOiBbVXNlcnNdIGRlZHVwbGljYXRpb248L2ZvbnQ+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRF Ij4NCjxibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGU+PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMw MDAwMDAiPmZyZSAyMDEzLTA1LTMxIGtsb2NrYW4gMDk6NTAgJiM0MzswMTAwIHNrcmV2IDxhIGhy ZWY9Im1haWx0bzpzdXBvcnRlQGxvZ2ljd29ya3MucHQiPg0Kc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0 PC9hPjogPC9mb250Pjxicj4NCjxibG9ja3F1b3RlPjxmb250IGNvbG9yPSIjMDAwMDAwIj5Tbywg d2UgY2FuIHNheSB0aGF0IGRlZHVwIGhhcyBtb3JlIGRpc2FkdmFudGFnZXMgdGhhbiBhZHZhbnRh Z2VzLjwvZm9udD48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAw MCI+Rm9yIGEgcHJpbWFyeSBzeXN0ZW07IG1vc3QgZGVmaW5pdGVseSwgeWVzLjwvZm9udD48YnI+ DQo8YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+QnV0IGZvciBhIGJhY2t1cCBzeXN0ZW0sIHRo YXQgaGFzIHRvbnMgb2YgUkFNIGFuZCBTU0QncyBmb3IgY2FjaGUsIGFuZCB5b3UgaGF2ZSBsb3Rz IG9mIHZpcnR1YWwgbWFjaGluZXMgdGhhdCBhcmUgYmFzZWQgb2ZmIG9mIHRoZSB0ZW1wbGF0ZSwg b3IgYXJlIHZlcnkgbXVjaCB0aGUgc2FtZSwgdGhlbiB5b3UgaGF2ZSBhIHJlYWwgdXNlLWNhc2Uu IEnCtG0gYWN0aXZlIGF0IHRoZSBGcmVlQlNEIGZvcnVtcyB3aGVyZQ0KIG9uZSBwZXJzb24gcmVw b3J0cyBzdG9yaW5nIDE1MFRCIG9mIGRhdGEgaW4gb25seSAzMFRCIG9mIHBoeXNpY2FsIGRpc2su IFRoZSBiZXN0IHByYWN0aWNlIG9mIHNjcnViYmluZyBpcyBvbmNlIGEgd2VlayBvbiAmcXVvdDtl bnRlcnByaXNlJnF1b3Q7IHN5c3RlbXMsIHRob3VnaCBoZSBpcyBvbmx5IGFibGUgdG8gZG8gaXQg b25jZSBhIG1vbnRoLCBiZWNhdXNlIHRoYXTCtHMgaG93IGxvbmcgaXQgdGFrZXMgZm9yIGEgc2Ny dWIgdG8gY29tcGxldGUgaW4gdGhhdCBzeXN0ZW0uDQogU28geW91wrR2ZSBnb3QgdG8gY2hvb3Nl IHBlcmZvcm1hbmNlIG9yIHNhdmluZ3MsIHlvdSBjYW7CtHQgaGF2ZSBib3RoLjwvZm9udD48YnI+ DQo8YnI+DQo8YmxvY2txdW90ZT48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+QW5kIHdoYXQg YWJvdXQgZGVkdXAgb2YgTmV0YXBwPzwvZm9udD48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8 Zm9udCBjb2xvcj0iIzAwMDAwMCI+TXVjaCBiZXR0ZXIgaW1wbGVtZW50YXRpb24sIGluIG15IG9w aW5pb24uIFlvdSBhcmUgYWJsZSBzY2hlZHVsZSBkZWR1cC1ydW5zIHRvIGdvIGF0IG5pZ2h0IHNv IHlvdXIgdXNlcsK0cyBwZXJmb3JtYW5jZSBpc27CtHQgaW1wYWN0ZWQsIGFuZCB5b3UgZ2V0IHRo ZSBzYXZpbmdzLiBUaGUgcXVlc3Rpb24gaXMgaWYgeW91IHZhbHVlIHRoZSBzYXZpbmdzIGVub3Vn aCB0byB0YWtlIG9uIHByaWNlLXRhZyB0aGF0IGlzDQogTmV0QXBwLiBPciBqdXN0IGJ1aWxkIHlv dXIgb3duIEZyZWVCU0QvWkZTIHNlcnZlciB3aXRoIGNvbXByZXNzaW9uIGVuYWJsZWQgYW5kIGJ1 eSBpbiBzdGFuZGFyZCBIREQncyBmcm9tIGFueXdoZXJlLi4uIFdlIGRpZDspPC9mb250Pjxicj4N Cjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj4vS2FybGk8L2ZvbnQ+PGJyPg0KPGJyPg0KPGJs b2NrcXVvdGU+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPkpvc2U8L2ZvbnQ+PGJyPg0KPGJy Pg0KPGhyIGFsaWduPSJjZW50ZXIiPg0KPGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPkZy b206IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiZxdW90O0thcmxpIFNqw7ZiZXJn JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86S2FybGkuU2pvYmVyZ0BzbHUuc2UiPkthcmxpLlNq b2JlcmdAc2x1LnNlPC9hPiZndDs8L2ZvbnQ+PGJyPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAwMDAi PlRvOiA8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIjMDAwMDAwIj48YSBocmVmPSJtYWlsdG86c3Vw b3J0ZUBsb2dpY3dvcmtzLnB0Ij5zdXBvcnRlQGxvZ2ljd29ya3MucHQ8L2E+PC9mb250Pjxicj4N CjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5DYzogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAw MDAwMCI+JnF1b3Q7SmlyaSBCZWxrYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpiZWxrYUBy ZWRoYXQuY29tIj5qYmVsa2FAcmVkaGF0LmNvbTwvYT4mZ3Q7LA0KPGEgaHJlZj0ibWFpbHRvOnVz ZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9hPjwvZm9udD48YnI+DQo8Yj48Zm9udCBj b2xvcj0iIzAwMDAwMCI+U2VudDogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+UXVp bnRhLWZlaXJhLCAzMCBkZSBNYWlvIGRlIDIwMTMgODozMzoxOTwvZm9udD48YnI+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDAwMCI+U3ViamVjdDogPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzAwMDAw MCI+UmU6IFtVc2Vyc10gZGVkdXBsaWNhdGlvbjwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+b25zIDIwMTMtMDUtMjkga2xvY2thbiAwOTo1OSAmIzQzOzAxMDAgc2tyZXYg PGEgaHJlZj0ibWFpbHRvOnN1cG9ydGVAbG9naWN3b3Jrcy5wdCI+DQpzdXBvcnRlQGxvZ2ljd29y a3MucHQ8L2E+OjwvZm9udD48YnI+DQo8YmxvY2txdW90ZT48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ QWJzb2x1dGVseSBhZ3JlZSB3aXRoIHlvdSwgcGxhbm5pbmcgaXMgdGhlIGJlc3QgdGhpbmcgdG8g ZG8sIGJ1dCBub3JtYWxseSBwZW9wbGUgd2FudCBhIHBsdWcnbidwbGF5IHN5c3RlbSB3aXRoIGFs bCBpbmNsdWRlZCwgYmVjYXVzZSB0aGVyZSBpcyBub3QgbXVjaCB0aW1lIHRvIHRoaW5rIGFuZCBw bGFubmluZywgYW5kIHRoZXJlIGFyZSBtYW55IGNvbXBhbmllcyB0aGF0IGtub3cgaG93DQogdG8g dGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBwZW9wbGUgY2hhcmFjdGVyaXN0aWNzLjwvZm9udD48YnI+ DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+QW55IHdheSwgSSB0aGluayBhbm90aGVyIHNvbHV0aW9u IGZvciBkZWR1cCBpcyBGcmVlTkFTIHVzaW5nIFpGUy48L2ZvbnQ+PGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPkZyZWVOQVMgaXMganVzdCBGcmVlQlNEIHdp dGggYSBmYW5jeSB3ZWItdWkgb250b3AsIHNvIGl0wrRzIG5laXRoZXIgbW9yZSBvciBsZXNzIG9m IFpGUyB0aGFuIHlvdSB3b3VsZCBoYXZlIG90aGVyd2lzZSwgQW5kIHJlZ2FyZGluZyBkZWR1cCBp biBaRlM7IEp1c3QgZG9uwrR0LCBpdMK0cyBub3Qgd29ydGggaXQhIEl0wrRzIHNhaWQgdGhhdCBp dDwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGI+bWF5PC9iPjwvZm9udD48Zm9udCBjb2xv cj0iIzAwMDAwMCI+DQogaW5jcmVhc2UgcGVyZm9ybWFuY2Ugd2hlbiB5b3UgaGF2ZSBhIHZlcnkg c3VpdGFibGUgdXNlY2FzZSwgZS5nLiBldmVyeXRoaW5nPC9mb250Pjxmb250IGNvbG9yPSIjMDAw MDAwIj48Yj5leGFjdGx5PC9iPjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+IHRoZSBzYW1l IG92ZXIgYW5kIG92ZXIuIFdoYXTCtHMgbm90IHNhaWQgaXMgdGhhdCBzY3J1YmJpbmcgYW5kIHJl c2lsdmVyaW5nIHNsb3dzIGRvd24gdG8gYSBzbmFpbCAoZnJvbSBodW5kcmVkcw0KIG9mIE1CL3Ms IG9yIEdCIGlmIHlvdXIgc3lzdGVtIGlzIGxhcmdlIGVub3VnaCwgZG93biB0byBsZXNzIHRoYW4g MTApLCBqdXN0IGZyb20gZGVkdXAuIEFsc28gZGVsZXRpbmcgc25hcHNob3RzIG9mIGRhdGFzZXRz IHRoYXQgaGF2ZShvciBoYXZlIGhhZCkgZGVkdXAgb24gY2FuIGtpbGwgdGhlIGVudGlyZSBzeXN0 ZW0sIGFuZCB3aGVuIEkgc2F5IGtpbGwsIEkgbWVhbiByZWFsbHkgZnViYXIuIEJlZW4gdGhlcmUs IHJlZ3JldHRlZCB0aGF0Li4uIE5vdywNCiBjb21wcmVzc2lvbiBvbiB0aGUgb3RoZXIgaGFuZCwg eW91IGdldCBiYXNpY2FsbHkgZm9yIGZyZWUgYW5kIGdpdmVzIGRlY2VudCBzYXZpbmdzLCBJIGhp Z2hseSByZWNvbW1lbmQgdGhhdC48L2ZvbnQ+PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMwMDAw MDAiPi9LYXJsaTwvZm9udD48YnI+DQo8YnI+DQo8YmxvY2txdW90ZT48YnI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+Sm9zZTwvZm9udD48YnI+DQo8YnI+DQo8YnI+DQo8aHIgYWxpZ249ImNlbnRl ciI+DQo8YnI+DQo8YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+RnJvbTogPC9mb250Pjwv Yj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+JnF1b3Q7SmlyaSBCZWxrYSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpiZWxrYUByZWRoYXQuY29tIj5qYmVsa2FAcmVkaGF0LmNvbTwvYT4mZ3Q7PC9m b250Pjxicj4NCjxiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5UbzogPC9mb250PjwvYj48Zm9udCBj b2xvcj0iIzAwMDAwMCI+PGEgaHJlZj0ibWFpbHRvOnN1cG9ydGVAbG9naWN3b3Jrcy5wdCI+c3Vw b3J0ZUBsb2dpY3dvcmtzLnB0PC9hPjwvZm9udD48YnI+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDAw MCI+Q2M6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxhIGhyZWY9Im1haWx0bzp1 c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT48L2ZvbnQ+PGJyPg0KPGI+PGZvbnQg Y29sb3I9IiMwMDAwMDAiPlNlbnQ6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlF1 YXJ0YS1mZWlyYSwgMjkgZGUgTWFpbyBkZSAyMDEzIDc6MzM6MTA8L2ZvbnQ+PGJyPg0KPGI+PGZv bnQgY29sb3I9IiMwMDAwMDAiPlN1YmplY3Q6IDwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAw MDAiPlJlOiBbVXNlcnNdIGRlZHVwbGljYXRpb248L2ZvbnQ+PGJyPg0KPGJyPg0KPGZvbnQgY29s b3I9IiMwMDAwMDAiPk9uIFR1ZSwgMjggTWF5IDIwMTMgMTQ6Mjk6MDUgJiM0MzswMTAwIChXRVNU KTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGEgaHJlZj0ibWFpbHRvOnN1cG9y dGVAbG9naWN3b3Jrcy5wdCI+c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PC9hPiB3cm90ZTo8L2ZvbnQ+ PGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPiZndDsgVGhhdCdzIHdoeSBJJ20gbWFr aW5nIHRoaXMgcXVlc3Rpb25zLCB0byBkZW15c3RpZnkgc29tZSBidXp6d29yZHMgYXJvdW5kIGhl cmUuPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj4mZ3Q7IEJ1dCBpZiB5b3UgaGF2 ZSBhIHN0cm9uZyBhbmQgZ29vZCB0ZWNobm9sb2d5IHdoeSBub3QgY3JlYXRlIGJ1enp3b3JkcyB0 byBnZXQgaW50byBhcyBtYW55IHBlb3BsZSBhcyBwb3NzaWJsZT8gd2l0aG91dCB0cmFwcGVkIHRo ZW0uPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj4mZ3Q7IFNoYXJlIGEgZGlzayBj b250YWluaW5nICZxdW90O3N0YXRpYyZxdW90OyBkYXRhIGlzIGEgZ29vZCBpZGVhLCBkbyB5b3Ug a25vdyBmcm9tIHdoZXJlIEkgY2FuIHN0YXJ0PzwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+RXZlcnl0aGluZyBkZXBlbmRzIG9uIHlvdXIgbmVlZHMsIGRlc2lnbiBwbGFu bmluZy4gTWF5YmUgdGhlbiBzaGFyaW5nPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAw Ij5kaXNrIHdvdWxkIGJlIGJldHRlciB0byBzaGFyZSB2aWEgTkZTL2lzY3NpLiBPZiBjb3Vyc2Ug aWYgeW91IGhhdmUgbWFueTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+Vk1zIGVh Y2ggb2YgdGhlbSBpcyBkaWZmZXJlbnQgeW91IHdpbGwgZmFpbC4gQnV0IGlmIHlvdSBoYXZlIG1v c3RseTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+aG9tb2dlbmVvdXMgZW52aXJv bm1lbnQgeW91IGNhbiB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNoLiBTdXJlIHlvdSBoYXZlPC9m b250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj50byBoYXZlIHBsYW4gZm9yIHVwZ3JhZGlu ZyAmcXVvdDtiYXNlJnF1b3Q7ICZxdW90O3N0YXRpYyZxdW90OyBzaGFyZWQgT1MgZGF0YSwgeW91 IGhhdmUgdG88L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPmhhdmUgcGxhbiBob3cg dG8gaW5zdGFsbCBhZGRpdGlvbmFsIHNvZnR3YXJlIChkaWZmZXJlbnQgZGVzdGluYXRpb248L2Zv bnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPnRoYW4gL3VzciBvciAvdXNyL2xvY2FsKS4u LiBJZiB5b3UgYWxyZWFkeSBoYXZlIHlvdXIgb3duIGJ1aWxkIGhvc3Q8L2ZvbnQ+PGJyPg0KPGZv bnQgY29sb3I9IiMwMDAwMDAiPndoaWNoIGJ1aWxkcyBmb3IgeW91IE9TIHBhY2thZ2VzIGFuZCB5 b3UgaGF2ZSBhbHJlYWR5IHlvdXIgb3duIHBsYW4gZm9yPC9mb250Pjxicj4NCjxmb250IGNvbG9y PSIjMDAwMDAwIj5kZXBsb3ltZW50LCB5b3UgaGF2ZSBkb25lIGZpcnN0IHN0ZXBzLiBJZiB5b3Ug ZGVwZW5kIG9uIHVwZ3JhZGluZyBlYWNoPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAw Ij5tYWNoaW5lIHNlcGFyYXRlbHkgZnJvbSBJbnRlcm5ldCwgdGhlbiBmaXJzdCB5b3Ugc2hvdWxk IHBsYW4geW91cjwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+ZW52aXJvbm1lbnQs IGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBldGMuPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNv bG9yPSIjMDAwMDAwIj5XZWxsLCBpbiBtYW55IHRpbWVzIHBlb3BsZSBkbyBub3QgZG8gYW55IHBs YW5uaW5nLCB0aGV5IGp1c3QgdGhpbmsgc29tZTwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAw MDAwMCI+Z29vZCB0ZWNobm9sb2d5IHdvdWxkIHNhdmUgdGhlaXIgJnF1b3Q7cG9vciZxdW90OyBk ZXNpZ24uPC9mb250Pjxicj4NCjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5qLjwvZm9udD48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8dGFibGUgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQ+LS0gPGJyPg0KPGJyPg0KTWVkIFbDpG5saWdhIEjDpGxzbmluZ2FyPGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCkthcmxpIFNqw7ZiZXJnPGJyPg0KU3dlZGlzaCBVbml2ZXJzaXR5 IG9mIEFncmljdWx0dXJhbCBTY2llbmNlczxicj4NCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNz IEtyb27DpXN2w6RnZW4gOCk8YnI+DQpTLTc1MCAwNyBVcHBzYWxhLCBTd2VkZW48YnI+DQpQaG9u ZTogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ2LSUyODAlMjkxOC02NyUyMDE1JTIwNjYiPiYjNDM7 NDYtKDApMTgtNjcgMTUgNjY8L2E+PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmthcmxpLnNqb2JlcmdA YWRtLnNsdS5zZSI+a2FybGkuc2pvYmVyZ0BzbHUuc2U8L2E+IDwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8dGFibGUgY2Vs bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQ+LS0gPGJyPg0KPGJyPg0KTWVkIFbDpG5saWdhIEjDpGxzbmluZ2FyPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCkthcmxpIFNqw7ZiZXJnPGJyPg0KU3dlZGlzaCBVbml2ZXJz aXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlczxicj4NCkJveCA3MDc5IChWaXNpdGluZyBBZGRy ZXNzIEtyb27DpXN2w6RnZW4gOCk8YnI+DQpTLTc1MCAwNyBVcHBzYWxhLCBTd2VkZW48YnI+DQpQ aG9uZTogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ2LSUyODAlMjkxOC02NyUyMDE1JTIwNjYiPiYj NDM7NDYtKDApMTgtNjcgMTUgNjY8L2E+PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmthcmxpLnNqb2Jl cmdAYWRtLnNsdS5zZSI+a2FybGkuc2pvYmVyZ0BzbHUuc2U8L2E+IDwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4NCjxibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGU+ PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlPjxicj4N Cjxmb250IGNvbG9yPSIjMDAwMDAwIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDAwMCI+VXNlcnMgbWFp bGluZyBsaXN0PC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj48YSBocmVmPSJtYWls dG86VXNlcnNAb3ZpcnQub3JnIj5Vc2Vyc0BvdmlydC5vcmc8L2E+PC9mb250Pjxicj4NCjxmb250 IGNvbG9yPSIjMDAwMDAwIj48YSBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4v bGlzdGluZm8vdXNlcnMiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91 c2VyczwvYT48L2ZvbnQ+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8YmxvY2txdW90ZT48YnI+ DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJD SVRFIj4NCjxibG9ja3F1b3RlPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+PGJyPg0KPGZvbnQgY29s b3I9IiMwMDAwMDAiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDAwIj5Vc2VycyBtYWlsaW5nIGxpc3Q8 L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiPjxhIGhyZWY9Im1haWx0bzpVc2Vyc0Bv dmlydC5vcmciPlVzZXJzQG92aXJ0Lm9yZzwvYT48L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMw MDAwMDAiPjxhIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91 c2VycyI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjwv Zm9udD48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJDSVRFIj48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJDSVRFIj48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRF Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+LS0gPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAw MDAwIj5DaHJpcyBOb2Zmc2luZ2VyPC9mb250Pjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9IkNJVEUiPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjx0 YWJsZSBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIj4NCjx0Ym9k eT4NCjx0cj4NCjx0ZD4tLSA8YnI+DQo8YnI+DQpNZWQgVsOkbmxpZ2EgSMOkbHNuaW5nYXI8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KS2FybGkgU2rDtmJlcmc8YnI+DQpTd2VkaXNo IFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzPGJyPg0KQm94IDcwNzkgKFZpc2l0 aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KTxicj4NClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRl bjxicj4NClBob25lOiAmbmJzcDsmIzQzOzQ2LSgwKTE4LTY3IDE1IDY2PGJyPg0KPGEgaHJlZj0i bWFpbHRvOmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZSI+a2FybGkuc2pvYmVyZ0BzbHUuc2U8L2E+ IDwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5F9E965F5A80BC468BE5F40576769F092E650438exchange21_--
Hello Jose, We are using only with iSCSI and as I have said it's working very well. We have three of this virtual servers that have the compression "lzjb" activated. The ratios are: Little server with Dovecot mail server has 21 GB and it has 8,6 GB real, save 60% space Little server with many log files has 11GB and it's using 2,2 GB real, save 80% space Little Windows Server OS for FlexLM and other software license control with 15 GB and it's using 9,2 GB real, save 40% space I hope this data are useful to you. Thanks, Juanjo. On Mon, Jun 3, 2013 at 6:12 PM, <suporte@logicworks.pt> wrote:
Hi Juan,
thanks for your info, I'll try to test FreeNAS with compression. Do you use it with iSCSI or NFS?
Jose
------------------------------ *From: *"Juan Jose" <jj197005@gmail.com> *To: *suporte@logicworks.pt, users@ovirt.org *Sent: *Segunda-feira, 3 de Junho de 2013 13:37:21 *Subject: *Re: [Users] deduplication
Hello Jose,
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.
Juanjo.
On Fri, May 31, 2013 at 12:33 PM, <suporte@logicworks.pt> wrote:
Thanks a lot Karli, you make my mind clear about deduplication, once again we cannot have the best of both worlds.
I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running on Linux, has no better performance but supports DRDB.
Jose
------------------------------ *From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Sexta-feira, 31 de Maio de 2013 10:45:41 *Subject: *Re: [Users] deduplication
fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt:
So, we can say that dedup has more disadvantages than advantages.
For a primary system; most definitely, yes.
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.
And what about dedup of Netapp?
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;)
/Karli
Jose
------------------------------
*From: *"Karli Sjöberg" <Karli.Sjoberg@slu.se> *To: *suporte@logicworks.pt *Cc: *"Jiri Belka" <jbelka@redhat.com>, users@ovirt.org *Sent: *Quinta-feira, 30 de Maio de 2013 8:33:19 *Subject: *Re: [Users] deduplication
ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt:
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. Any way, I think another solution for dedup is FreeNAS using ZFS.
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 *may* increase performance when you have a very suitable usecase, e.g. everything * exactly* 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.
/Karli
Jose
------------------------------
*From: *"Jiri Belka" <jbelka@redhat.com> *To: *suporte@logicworks.pt *Cc: *users@ovirt.org *Sent: *Quarta-feira, 29 de Maio de 2013 7:33:10 *Subject: *Re: [Users] deduplication
On Tue, 28 May 2013 14:29:05 +0100 (WEST) suporte@logicworks.pt wrote:
That's why I'm making this questions, to demystify some buzzwords around here. But if you have a strong and good technology why not create buzzwords to get into as many people as possible? without trapped them. Share a disk containing "static" data is a good idea, do you know from where I can start?
Everything depends on your needs, design planning. Maybe then sharing disk would be better to share via NFS/iscsi. Of course if you have many VMs each of them is different you will fail. But if you have mostly homogeneous environment you can think about this approach. Sure you have to have plan for upgrading "base" "static" shared OS data, you have to have plan how to install additional software (different destination than /usr or /usr/local)... If you already have your own build host which builds for you OS packages and you have already your own plan for deployment, you have done first steps. If you depend on upgrading each machine separately from Internet, then first you should plan your environment, configuration management etc.
Well, in many times people do not do any planning, they just think some good technology would save their "poor" design.
j.
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
--
Med Vänliga Hälsningar
------------------------------------------------------------------------------- Karli Sjöberg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kronåsvägen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se <karli.sjoberg@adm.slu.se>
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
------=_Part_237_16733285.1370360396749 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juanjo,=20 Very useful, thanks a lot.You save a medium of 60%.=20 Thanks=20 ----- Original Message ----- From: "Juan Jose" <jj197005@gmail.com>=20 To: suporte@logicworks.pt, users@ovirt.org=20 Sent: Ter=C3=A7a-feira, 4 de Junho de 2013 12:39:02=20 Subject: Re: [Users] deduplication=20 Hello Jose,=20 We are using only with iSCSI and as I have said it's working very well. We = have three of this virtual servers that have the compression "lzjb" activat= ed. The ratios are:=20 Little server with Dovecot mail server has 21 GB and it has 8,6 GB real, sa= ve 60% space=20 Little server with many log files has 11GB and it's using 2,2 GB real, save= 80% space=20 Little Windows Server OS for FlexLM and other software license control with= 15 GB and it's using 9,2 GB real, save 40% space=20 I hope this data are useful to you.=20 Thanks,=20 Juanjo.=20 On Mon, Jun 3, 2013 at 6:12 PM, < suporte@logicworks.pt > wrote:=20 Hi Juan,=20 thanks for your info, I'll try to test FreeNAS with compression. Do you use= it with iSCSI or NFS?=20 Jose=20 From: "Juan Jose" < jj197005@gmail.com >=20 To: suporte@logicworks.pt , users@ovirt.org=20 Sent: Segunda-feira, 3 de Junho de 2013 13:37:21=20 Subject: Re: [Users] deduplication=20 Hello Jose,=20 We also have FreeNAS working in our infraestructure, with about 3 TB and ZF= S. 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 an= d other paravirtualized, and some Windows Server machine all about 2 years = in production without any problem. My idea is connect this infrastructure w= ith oVirt wo be able to have some resources for test VMs in that. Only want= ed to share as another FreeNas success experience.=20 Juanjo.=20 On Fri, May 31, 2013 at 12:33 PM, < suporte@logicworks.pt > wrote:=20 <blockquote> Thanks a lot Karli, you make my mind clear about deduplication, once again = we cannot have the best of both worlds.=20 I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, running o= n Linux, has no better performance but supports DRDB.=20 Jose=20 From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Sexta-feira, 31 de Maio de 2013 10:45:41=20 Subject: Re: [Users] deduplication=20 fre 2013-05-31 klockan 09:50 +0100 skrev suporte@logicworks.pt :=20 <blockquote> So, we can say that dedup has more disadvantages than advantages.=20 For a primary system; most definitely, yes.=20 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4= s how long it takes for a scrub to complete in that system. So you=C2=B4ve = got to choose performance or savings, you can=C2=B4t have both.=20 <blockquote> And what about dedup of Netapp?=20 </blockquote> Much better implementation, in my opinion. You are able schedule dedup-runs= to go at night so your user=C2=B4s performance isn=C2=B4t impacted, and yo= u 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;)=20 /Karli=20 <blockquote> Jose=20 </blockquote> <blockquote> From: "Karli Sj=C3=B6berg" < Karli.Sjoberg@slu.se >=20 To: suporte@logicworks.pt=20 Cc: "Jiri Belka" < jbelka@redhat.com >, users@ovirt.org=20 Sent: Quinta-feira, 30 de Maio de 2013 8:33:19=20 Subject: Re: [Users] deduplication=20 ons 2013-05-29 klockan 09:59 +0100 skrev suporte@logicworks.pt :=20 <blockquote> Absolutely agree with you, planning is the best thing to do, but normally p= eople want a plug'n'play system with all included, because there is not muc= h time to think and planning, and there are many companies that know how to= take advantage of this people characteristics.=20 Any way, I think another solution for dedup is FreeNAS using ZFS.=20 </blockquote> FreeNAS is just FreeBSD with a fancy web-ui ontop, so it=C2=B4s neither mor= e or less of ZFS than you would have otherwise, And regarding dedup in ZFS;= Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s said that it may increa= se performance when you have a very suitable usecase, e.g. everything exact= ly the same over and over. What=C2=B4s not said is that scrubbing and resil= vering slows down to a snail (from hundreds of MB/s, or GB if your system i= s large enough, down to less than 10), just from dedup. Also deleting snaps= hots 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... N= ow, compression on the other hand, you get basically for free and gives dec= ent savings, I highly recommend that.=20 /Karli=20 <blockquote> Jose=20 From: "Jiri Belka" < jbelka@redhat.com >=20 To: suporte@logicworks.pt=20 Cc: users@ovirt.org=20 Sent: Quarta-feira, 29 de Maio de 2013 7:33:10=20 Subject: Re: [Users] deduplication=20 On Tue, 28 May 2013 14:29:05 +0100 (WEST)=20 suporte@logicworks.pt wrote:=20
That's why I'm making this questions, to demystify some buzzwords around = here.=20 But if you have a strong and good technology why not create buzzwords to = get into as many people as possible? without trapped them.=20 Share a disk containing "static" data is a good idea, do you know from wh= ere I can start?=20
<div>Thanks,</div><div><br></div><div>Juanjo.</div></div><div class=3D"gma= il_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 3, 2013 at 6:12 PM= , <span dir=3D"ltr"><<a href=3D"mailto:suporte@logicworks.pt" target=3D= "_blank">suporte@logicworks.pt</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style= =3D"font-size: 10pt; font-family: arial,helvetica,sans-serif;">Hi Juan,<br>= <br>thanks for your info, I'll try to test FreeNAS with compression. Do you= use it with iSCSI or NFS?<br> <br>Jose<br><br><hr><div style=3D"font-size: 12pt; font-style: normal; font= -family: Helvetica,Arial,sans-serif; text-decoration: none; font-weight: no= rmal;"><b>From: </b>"Juan Jose" <<a href=3D"mailto:jj197005@gmail.com" t= arget=3D"_blank">jj197005@gmail.com</a>><br> <b>To: </b><a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">supor= te@logicworks.pt</a>, <a href=3D"mailto:users@ovirt.org" target=3D"_blank">= users@ovirt.org</a><br><b>Sent: </b>Segunda-feira, 3 de Junho de 2013 13:37= :21<br> <b>Subject: </b>Re: [Users] deduplication<div><div class=3D"h5"><br><br><di= v dir=3D"ltr"><br><div>Hello Jose,</div><div><br></div><div>We also have Fr= eeNAS working in our infraestructure, with about 3 TB and ZFS. Some of the =
Everything depends on your needs, design planning. Maybe then sharing=20 disk would be better to share via NFS/iscsi. Of course if you have many=20 VMs each of them is different you will fail. But if you have mostly=20 homogeneous environment you can think about this approach. Sure you have=20 to have plan for upgrading "base" "static" shared OS data, you have to=20 have plan how to install additional software (different destination=20 than /usr or /usr/local)... If you already have your own build host=20 which builds for you OS packages and you have already your own plan for=20 deployment, you have done first steps. If you depend on upgrading each=20 machine separately from Internet, then first you should plan your=20 environment, configuration management etc.=20 Well, in many times people do not do any planning, they just think some=20 good technology would save their "poor" design.=20 j.=20 </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 </blockquote> <blockquote> </blockquote> =09--=20 Med V=C3=A4nliga H=C3=A4lsningar=20 ---------------------------------------------------------------------------= ----=20 Karli Sj=C3=B6berg=20 Swedish University of Agricultural Sciences=20 Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)=20 S-750 07 Uppsala, Sweden=20 Phone: +46-(0)18-67 15 66=20 karli.sjoberg@slu.se=20 _______________________________________________=20 Users mailing list=20 Users@ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 </blockquote> </blockquote> ------=_Part_237_16733285.1370360396749 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>Hi Juanjo,<br><br>Very useful, thanks a lot.You save a medium o= f 60%. <br><br>Thanks <br><br><hr id=3D"zwchr"><div style=3D"color: rgb(0, = 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font= -family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Juan J= ose" <jj197005@gmail.com><br><b>To: </b>suporte@logicworks.pt, users@= ovirt.org<br><b>Sent: </b>Ter=C3=A7a-feira, 4 de Junho de 2013 12:39:02<br>= <b>Subject: </b>Re: [Users] deduplication<br><br><div dir=3D"ltr"><br><div>= Hello Jose,</div><div><br></div><div>We are using only with iSCSI and as I = have said it's working very well. We have three of this virtual servers tha= t have the compression "lzjb" activated. The ratios are:</div> <div><br></div><div>Little server with Dovecot mail server has 21 GB and it= has 8,6 GB real, save 60% space</div><div>Little server with many log file= s has 11GB and it's using 2,2 GB real, save 80% space</div><div>Littl= e Windows Server OS for FlexLM and other software license control with 15 G= B and it's using 9,2 GB real, save 40% space</div> <div><br></div><div>I hope this data are useful to you.</div><div><br></div= 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 stabl= e and sure. We have nine virtual servers some wirtualized and other paravir= tualized, and some Windows Server machine all about 2 years in production w= ithout 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=3D"gmail_extra"><br><br><= div class=3D"gmail_quote">On Fri, May 31, 2013 at 12:33 PM, <span dir=3D"l= tr"><<a href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@= logicworks.pt</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style= =3D"font-size: 10pt; font-family: arial,helvetica,sans-serif;">Thanks a lot= Karli, you make my mind clear about deduplication, once again we cannot ha= ve the best of both worlds.<br> <br>I'll try FreeNAS despite my poor knowledge on FreeBSD. Openfiler, runni= ng on Linux, has no better performance but supports DRDB.<br><br>Jose<br><b= r><hr><div style=3D"font-size: 12pt; font-style: normal; font-family: Helve= tica,Arial,sans-serif; text-decoration: none; font-weight: normal;"> <div><b>From: </b>"Karli Sj=C3=B6berg" <<a href=3D"mailto:Karli.Sjoberg@= slu.se" target=3D"_blank">Karli.Sjoberg@slu.se</a>><br><b>To: </b><a hre= f=3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt<= /a><br> <b>Cc: </b>"Jiri Belka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"= _blank">jbelka@redhat.com</a>>, <a href=3D"mailto:users@ovirt.org" targe= t=3D"_blank">users@ovirt.org</a><br></div><b>Sent: </b>Sexta-feira, 31 de M= aio de 2013 10:45:41<br> <b>Subject: </b>Re: [Users] deduplication<div><div><br><br> fre 2013-05-31 klockan 09:50 +0100 skrev <a href=3D"mailto:suporte@logicwor= ks.pt" target=3D"_blank">suporte@logicworks.pt</a>: <blockquote><font color=3D"#000000">So, we can say that dedup has more disa= dvantages 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 ve= ry much the same, then you have a real use-case. I=C2=B4m active at the Fre= eBSD 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=C2=B4s how long it takes for a scrub to c= omplete in that system. So you=C2=B4ve got to choose performance or savings, you can=C2=B4t have both.<br> <br> <blockquote><br> <font color=3D"#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=C2=B4s performance isn=C2=B4t impacted, and yo= u 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 H= DD's from anywhere... We did;)<br> <br> /Karli<br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <hr align=3D"center"> </blockquote> <blockquote><b><font color=3D"#000000">From: </font></b><font color=3D"#000= 000">"Karli Sj=C3=B6berg" <<a href=3D"mailto:Karli.Sjoberg@slu.se" targe= t=3D"_blank">Karli.Sjoberg@slu.se</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000">"Jiri Bel= ka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@redha= t.com</a>>, <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@o= virt.org</a></font><br> <b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quinta-= feira, 30 de Maio de 2013 8:33:19</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">ons 2013-05-29 klockan 09:59 +0100 skrev <a href=3D= "mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</a>: </font><br> <blockquote><font color=3D"#000000">Absolutely agree with you, planning is = the best thing to do, but normally people want a plug'n'play system with al= l 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=3D"#000000">Any way, I think another solution for dedup is Free= NAS using ZFS.</font><br> </blockquote> <br> <font color=3D"#000000">FreeNAS is just FreeBSD with a fancy web-ui ontop, = so it=C2=B4s neither more or less of ZFS than you would have otherwise, And= regarding dedup in ZFS; Just don=C2=B4t, it=C2=B4s not worth it! It=C2=B4s= said that it </font><font color=3D"#000000"><b>may</b></font><font color=3D"#000000"> in= crease performance when you have a very suitable usecase, e.g. everything </font><font color=3D"#000000"><b>exactly</b></font><font color=3D"#000000"=
the same over and over. What=C2=B4s not said is that scrubbing and resilv= ering 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) ded= up 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=3D"#000000">/Karli</font><br> <br> <blockquote><br> <font color=3D"#000000">Jose</font><br> <br> <br> <hr align=3D"center"> <br> <b><font color=3D"#000000">From: </font></b><font color=3D"#000000">"Jiri B= elka" <<a href=3D"mailto:jbelka@redhat.com" target=3D"_blank">jbelka@red= hat.com</a>></font><br> <b><font color=3D"#000000">To: </font></b><font color=3D"#000000"><a href= =3D"mailto:suporte@logicworks.pt" target=3D"_blank">suporte@logicworks.pt</= a></font><br> <b><font color=3D"#000000">Cc: </font></b><font color=3D"#000000"><a href= =3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a></font><br=
<b><font color=3D"#000000">Sent: </font></b><font color=3D"#000000">Quarta-= feira, 29 de Maio de 2013 7:33:10</font><br> <b><font color=3D"#000000">Subject: </font></b><font color=3D"#000000">Re: = [Users] deduplication</font><br> <br> <font color=3D"#000000">On Tue, 28 May 2013 14:29:05 +0100 (WEST)</font><br=
<font color=3D"#000000"><a href=3D"mailto:suporte@logicworks.pt" target=3D"= _blank">suporte@logicworks.pt</a> wrote:</font><br> <br> <font color=3D"#000000">> That's why I'm making this questions, to demys= tify some buzzwords around here.</font><br> <font color=3D"#000000">> But if you have a strong and good technology w= hy not create buzzwords to get into as many people as possible? without tra= pped them.</font><br> <font color=3D"#000000">> Share a disk containing "static" data is a goo= d idea, do you know from where I can start?</font><br> <br> <font color=3D"#000000">Everything depends on your needs, design planning. = Maybe then sharing</font><br> <font color=3D"#000000">disk would be better to share via NFS/iscsi. Of cou= rse if you have many</font><br> <font color=3D"#000000">VMs each of them is different you will fail. But if= you have mostly</font><br> <font color=3D"#000000">homogeneous environment you can think about this ap= proach. Sure you have</font><br> <font color=3D"#000000">to have plan for upgrading "base" "static" shared O= S data, you have to</font><br> <font color=3D"#000000">have plan how to install additional software (diffe= rent destination</font><br> <font color=3D"#000000">than /usr or /usr/local)... If you already have you= r own build host</font><br> <font color=3D"#000000">which builds for you OS packages and you have alrea= dy your own plan for</font><br> <font color=3D"#000000">deployment, you have done first steps. If you depen= d on upgrading each</font><br> <font color=3D"#000000">machine separately from Internet, then first you sh= ould plan your</font><br> <font color=3D"#000000">environment, configuration management etc.</font><b= r> <br> <font color=3D"#000000">Well, in many times people do not do any planning, = they just think some</font><br> <font color=3D"#000000">good technology would save their "poor" design.</fo= nt><br> <br> <font color=3D"#000000">j.</font><br> <br> <br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </blockquote> <blockquote><br> <br> </blockquote> <br> <table cellpadding=3D"0" cellspacing=3D"0" width=3D"100%"> <tbody> <tr> <td>-- <br> <br> Med V=C3=A4nliga H=C3=A4lsningar<br> ---------------------------------------------------------------------------= ----<br> Karli Sj=C3=B6berg<br> Swedish University of Agricultural Sciences<br> Box 7079 (Visiting Address Kron=C3=A5sv=C3=A4gen 8)<br> S-750 07 Uppsala, Sweden<br> Phone: +46-(0)18-67 15 66<br> <a href=3D"mailto:karli.sjoberg@adm.slu.se" target=3D"_blank">karli.sjoberg= @slu.se</a> </td> </tr> </tbody> </table> </div></div></div><br></div></div><br>_____________________________________= __________<br> Users mailing list<br> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users@ovirt.org</a><br=
<a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"=
http://lists.ovirt.org/mailman/listinfo/users</a><br> <br></blockquote></div><br></div> </div></div></div><br></div></div></blockquote></div><br></div> </div><br></div></body></html> ------=_Part_237_16733285.1370360396749--
participants (6)
-
Chris Noffsinger -
Jiri Belka -
Juan Jose -
Karli Sjöberg -
suporte＠logicworks.pt -
Theron Conrey