9:02 a.m.
------=_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--
3 p.m.
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(a)logicworks.pt
To: Users(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:20 a.m.
------=_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(a)redhat.com>=20
To: suporte(a)logicworks.pt=20
Cc: Users(a)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(a)logicworks.pt=20
To: Users(a)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(a)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"
&lt;tconrey(a)redhat.com&gt;<br><b>To: </b>suporte@lo=
gicworks.pt<br><b>Cc: </b>Users(a)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=
Hi Jose,<br><br>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 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(a)logicworks.pt<br>To:
Users(a)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(a)ovirt.org<b=
r>http://lists.ovirt.org/mailman/listinfo/users<br></div>&...
/html>
------=_Part_665_15117543.1369732848335--
6 a.m.
On Sat, 25 May 2013 15:02:40 +0100 (WEST)
suporte(a)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.
6:05 a.m.
On Tue, 28 May 2013 13:00:36 +0200
Jiri Belka <jbelka(a)redhat.com> wrote:
On Sat, 25 May 2013 15:02:40 +0100 (WEST)
suporte(a)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.
8:29 a.m.
------=_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(a)redhat.com>=20
To: users(a)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(a)redhat.com> wrote:=20
On Sat, 25 May 2013 15:02:40 +0100 (WEST)=20
suporte(a)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(a)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"
&lt;jbelka(a)redhat.com&gt;<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 &lt;jbelka(a)redhat.com&gt;
wrote:<br><br>> On Sat, 25 M=
ay 2013 15:02:40 +0100 (WEST)<br>> suporte(a)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>&l...
</body></html>
------=_Part_1368_23539899.1369747751212--
1:33 a.m.
On Tue, 28 May 2013 14:29:05 +0100 (WEST)
suporte(a)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.
3:59 a.m.
------=_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(a)redhat.com>
To: suporte(a)logicworks.pt
Cc: users(a)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(a)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"
&lt;jbelka(a)redhat.com&=
gt;<br><b>To: </b>suporte(a)logicworks.pt<br><b>Cc:
</b>users(a)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(a)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--
2:33 a.m.
--_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_--
3:50 a.m.
------=_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(a)slu.se>=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)redhat.com>=20
To: suporte(a)logicworks.pt=20
Cc: users(a)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(a)logicworks.pt wrote:=20
<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(a)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"
&lt;Karli.Sjoberg(a)slu.se&gt;<b=
r><b>To: </b>suporte(a)logicworks.pt<br><b>Cc:
</b>"Jiri Belka" <jbelka@re=
dhat.com>, users(a)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(a)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"
&lt;jbelka(a)redhat.com&gt;</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(a)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--
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
4:45 a.m.
--_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_--
5:33 a.m.
------=_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(a)slu.se>=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)slu.se>=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)redhat.com>=20
To: suporte(a)logicworks.pt=20
Cc: users(a)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(a)logicworks.pt wrote:=20
=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(a)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(a)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"
&lt;Karli.Sjoberg(a)slu.se&gt;<br><b=
fre 2013-05-31 klockan 09:50 +0100 skrev suporte(a)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"
&lt;Karli.Sjoberg(a)slu.se&gt;</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" &lt;jbelka(a)redhat.com&gt;, users(a)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"=
<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" &lt;jbelka(a)redhat.com&gt;</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(a)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--
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
</blockquoteTo: </b>suporte(a)logicworks.pt<br><b>Cc:
</b>"Jiri Belka" <jbelka@redhat=
.com>,
users(a)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 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
7:37 a.m.
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(a)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(a)slu.se>
*To: *suporte(a)logicworks.pt
*Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)slu.se>
*To: *suporte(a)logicworks.pt
*Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)redhat.com>
*To: *suporte(a)logicworks.pt
*Cc: *users(a)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(a)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(a)slu.se <karli.sjoberg(a)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(a)slu.se <karli.sjoberg(a)adm.slu.se>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:12 a.m.
------=_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(a)gmail.com>=20
To: suporte(a)logicworks.pt, users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)redhat.com >=20
To: suporte(a)logicworks.pt=20
Cc: users(a)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(a)logicworks.pt wrote:=20
=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(a)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(a)slu.se=20
_______________________________________________=20
Users mailing list=20
Users(a)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"
&lt;jj197005(a)gmail.com&gt;<br>=
<b>To: </b>suporte(a)logicworks.pt, users(a)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(a)slu.se"
target=3D"_blank">Karli.Sjoberg(a)slu.se</a>&gt;<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(a)redhat.com</a>&gt;, <a
href=3D"mailto:users@ovirt.org" targe=
t=3D"_blank">users(a)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(a)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(a)slu.se</a>&gt;</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(a)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(a)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"=
<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(a)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(a)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(a)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(a)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--
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 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
11:16 a.m.
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(a)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(a)gmail.com>
*To: *suporte(a)logicworks.pt, users(a)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(a)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(a)slu.se>
> *To: *suporte(a)logicworks.pt
> *Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)slu.se>
> *To: *suporte(a)logicworks.pt
> *Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)redhat.com>
> *To: *suporte(a)logicworks.pt
> *Cc: *users(a)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(a)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(a)slu.se <karli.sjoberg(a)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(a)slu.se <karli.sjoberg(a)adm.slu.se>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Chris Noffsinger
12:26 p.m.
------=_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(a)gmail.com>=20
To: suporte(a)logicworks.pt=20
Cc: "Juan Jose" <jj197005(a)gmail.com>, users(a)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(a)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(a)gmail.com >=20
To: suporte(a)logicworks.pt , users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)redhat.com >=20
To: suporte(a)logicworks.pt=20
Cc: users(a)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(a)logicworks.pt wrote:=20
=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(a)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(a)slu.se=20
_______________________________________________=20
Users mailing list=20
Users(a)ovirt.org=20
http://lists.ovirt.org/mailman/listinfo/users=20
</blockquote
_______________________________________________=20
Users mailing list=20
Users(a)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(a)gmail.com&gt;<br><b>To:
</b>suporte(a)logicworks.pt<br><b>Cc: </b>=
"Juan Jose" &lt;jj197005(a)gmail.com&gt;,
users(a)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(a)logicworks.pt</a>&gt;</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(a)gmail.com</a>&gt;<br><b>To:
</b><a href=3D"mailto:supo=
rte(a)logicworks.pt" target=3D"_blank">suporte(a)logicworks.pt</a>,
<a href=3D"=
mailto:users@ovirt.org"
target=3D"_blank">users(a)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=
<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(a)slu.se</a>&gt;<br><b>To:
</b><a hre=
f=3D"mailto:suporte@logicworks.pt"
target=3D"_blank">suporte(a)logicworks.pt<=
/a><br
<b>Cc: </b>"Jiri Belka" <<a
href=3D"mailto:jbelka@redhat.com" target=3D"=
_blank">jbelka(a)redhat.com</a>&gt;, <a
href=3D"mailto:users@ovirt.org" targe=
t=3D"_blank">users(a)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(a)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(a)slu.se</a>&gt;</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(a)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(a)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"=
<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(a)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(a)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(a)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(a)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(a)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--
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<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 =
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 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
2:38 a.m.
--_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_--
6:39 a.m.
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(a)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(a)gmail.com>
*To: *suporte(a)logicworks.pt, users(a)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(a)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(a)slu.se>
> *To: *suporte(a)logicworks.pt
> *Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)slu.se>
> *To: *suporte(a)logicworks.pt
> *Cc: *"Jiri Belka" <jbelka(a)redhat.com>, users(a)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(a)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(a)redhat.com>
> *To: *suporte(a)logicworks.pt
> *Cc: *users(a)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(a)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(a)slu.se <karli.sjoberg(a)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(a)slu.se <karli.sjoberg(a)adm.slu.se>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
10:39 a.m.
------=_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(a)gmail.com>=20
To: suporte(a)logicworks.pt, users(a)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(a)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(a)gmail.com >=20
To: suporte(a)logicworks.pt , users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)slu.se >=20
To: suporte(a)logicworks.pt=20
Cc: "Jiri Belka" < jbelka(a)redhat.com >, users(a)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(a)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(a)redhat.com >=20
To: suporte(a)logicworks.pt=20
Cc: users(a)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(a)logicworks.pt wrote:=20
=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(a)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(a)slu.se=20
_______________________________________________=20
Users mailing list=20
Users(a)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" &lt;jj197005(a)gmail.com&gt;<br><b>To:
</b>suporte(a)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=
<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(a)gmail.com</a>&gt;<br <b>To: </b><a
href=3D"mailto:suporte@logicworks.pt" target=3D"_blank">supor=
te(a)logicworks.pt</a>, <a href=3D"mailto:users@ovirt.org"
target=3D"_blank">=
users(a)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 =
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(a)slu.se</a>&gt;<br><b>To:
</b><a hre=
f=3D"mailto:suporte@logicworks.pt"
target=3D"_blank">suporte(a)logicworks.pt<=
/a><br
<b>Cc: </b>"Jiri Belka" <<a
href=3D"mailto:jbelka@redhat.com" target=3D"=
_blank">jbelka(a)redhat.com</a>&gt;, <a
href=3D"mailto:users@ovirt.org" targe=
t=3D"_blank">users(a)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(a)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(a)slu.se</a>&gt;</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(a)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(a)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"=
<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(a)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(a)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(a)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(a)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--
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<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(a)logicworks.pt</a>&gt;</span>
wrote:<br 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
3978
days inactive
3988
days old
18 comments
6 participants
participants (6)
-
Chris Noffsinger -
Jiri Belka -
Juan Jose -
Karli Sjöberg -
suporte＠logicworks.pt -
Theron Conrey