On Mon, May 9, 2011 at 2:11 AM, Evaldas Auryla evaldas.aur...@edqm.euwrote:
On 05/ 6/11 07:21 PM, Brandon High wrote:
On Fri, May 6, 2011 at 9:15 AM, Ray Van Dolsonrvandol...@esri.com
wrote:
We use dedupe on our VMware datastores and typically see 50% savings,
often times more. We do of
On Wed, May 04, 2011 at 08:49:03PM -0700, Edward Ned Harvey wrote:
From: Tim Cook [mailto:t...@cook.ms]
That's patently false. VM images are the absolute best use-case for dedup
outside of backup workloads. I'm not sure who told you/where you got the
idea that VM images are not ripe
On Fri, May 6, 2011 at 9:15 AM, Ray Van Dolson rvandol...@esri.com wrote:
We use dedupe on our VMware datastores and typically see 50% savings,
often times more. We do of course keep like VM's on the same volume
I think NetApp uses 4k blocks by default, so the block size and
alignment should
From: Garrett D'Amore [mailto:garr...@nexenta.com]
We have customers using dedup with lots of vm images... in one extreme
case they are getting dedup ratios of over 200:1!
I assume you're talking about a situation where there is an initial VM image,
and then to clone the machine, the
Hi,
On 05/ 5/11 03:02 PM, Edward Ned Harvey wrote:
From: Garrett D'Amore [mailto:garr...@nexenta.com]
We have customers using dedup with lots of vm images... in one extreme
case they are getting dedup ratios of over 200:1!
I assume you're talking about a situation where there is an initial
On Thu, 2011-05-05 at 09:02 -0400, Edward Ned Harvey wrote:
From: Garrett D'Amore [mailto:garr...@nexenta.com]
We have customers using dedup with lots of vm images... in one extreme
case they are getting dedup ratios of over 200:1!
I assume you're talking about a situation where there
I assume you're talking about a situation where there is an initial VM image,
and then to clone the machine, the customers copy the VM, correct?
If that is correct, have you considered ZFS cloning instead?
When I said dedup wasn't good for VM's, what I'm talking about is: If there is data
We have customers using dedup with lots of vm images... in one extreme case
they are getting dedup ratios of over 200:1!
You don't need dedup or sparse files for zero filling. Simple zle compression
will eliminate those for you far more efficiently and without needing massive
amounts of ram.
On Wed, May 4, 2011 at 8:23 PM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
Generally speaking, dedup doesn't work on VM images. (Same is true for ZFS
or netapp or anything else.) Because the VM images are all going to have
their own filesystems internally with
On May 5, 2011, at 2:58 PM, Brandon High wrote:
On Wed, May 4, 2011 at 8:23 PM, Edward Ned Harvey
Or if you're intimately familiar with both the guest host filesystems, and
you choose blocksizes carefully to make them align. But that seems
complicated and likely to fail.
Using a 4k
On May 5, 2011, at 6:02 AM, Edward Ned Harvey wrote:
Is this a zfs discussion list, or a nexenta sales promotion list?
Obviously, this is a Nextenta sales promotion list. And Oracle. And OSX.
And BSD. And Linux. And anyone who needs help or can offer help with ZFS
technology :-) This list has
From: Brandon High [mailto:bh...@freaks.com]
On Wed, May 4, 2011 at 8:23 PM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
Generally speaking, dedup doesn't work on VM images. (Same is true for
ZFS
or netapp or anything else.) Because the VM images are all
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
If you have to use the 4k recordsize, it is likely to consume 32x more
memory than the default 128k recordsize of ZFS. At this rate, it becomes
increasingly difficult to
On Thu, May 5, 2011 at 8:50 PM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
If you have to use the 4k recordsize, it is likely to consume 32x more
memory than the default 128k recordsize of ZFS. At this rate, it becomes
increasingly difficult to get a
There are a number of threads (this one[1] for example) that describe
memory requirements for deduplication. They're pretty high.
I'm trying to get a better understanding... on our NetApps we use 4K
block sizes with their post-process deduplication and get pretty good
dedupe ratios for VM
On 5/4/2011 9:57 AM, Ray Van Dolson wrote:
There are a number of threads (this one[1] for example) that describe
memory requirements for deduplication. They're pretty high.
I'm trying to get a better understanding... on our NetApps we use 4K
block sizes with their post-process deduplication
On Wed, May 04, 2011 at 12:29:06PM -0700, Erik Trimble wrote:
On 5/4/2011 9:57 AM, Ray Van Dolson wrote:
There are a number of threads (this one[1] for example) that describe
memory requirements for deduplication. They're pretty high.
I'm trying to get a better understanding... on our
On Wed, May 4, 2011 at 12:29 PM, Erik Trimble erik.trim...@oracle.com wrote:
I suspect that NetApp does the following to limit their resource
usage: they presume the presence of some sort of cache that can be
dedicated to the DDT (and, since they also control the hardware, they can
On 5/4/2011 2:54 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 12:29:06PM -0700, Erik Trimble wrote:
(2) Block size: a 4k block size will yield better dedup than a 128k
block size, presuming reasonable data turnover. This is inherent, as
any single bit change in a block will make it
On Wed, May 04, 2011 at 02:55:55PM -0700, Brandon High wrote:
On Wed, May 4, 2011 at 12:29 PM, Erik Trimble erik.trim...@oracle.com wrote:
I suspect that NetApp does the following to limit their resource
usage: they presume the presence of some sort of cache that can be
dedicated
On Wed, May 04, 2011 at 03:49:12PM -0700, Erik Trimble wrote:
On 5/4/2011 2:54 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 12:29:06PM -0700, Erik Trimble wrote:
(2) Block size: a 4k block size will yield better dedup than a 128k
block size, presuming reasonable data turnover. This
On 5/4/2011 4:14 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 02:55:55PM -0700, Brandon High wrote:
On Wed, May 4, 2011 at 12:29 PM, Erik Trimbleerik.trim...@oracle.com wrote:
I suspect that NetApp does the following to limit their resource
usage: they presume the presence of
On Wed, May 4, 2011 at 6:36 PM, Erik Trimble erik.trim...@oracle.comwrote:
On 5/4/2011 4:14 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 02:55:55PM -0700, Brandon High wrote:
On Wed, May 4, 2011 at 12:29 PM, Erik Trimbleerik.trim...@oracle.com
wrote:
I suspect that NetApp
On 5/4/2011 4:17 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 03:49:12PM -0700, Erik Trimble wrote:
On 5/4/2011 2:54 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 12:29:06PM -0700, Erik Trimble wrote:
(2) Block size: a 4k block size will yield better dedup than a 128k
block size,
On 5/4/2011 4:44 PM, Tim Cook wrote:
On Wed, May 4, 2011 at 6:36 PM, Erik Trimble erik.trim...@oracle.com
mailto:erik.trim...@oracle.com wrote:
On 5/4/2011 4:14 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 02:55:55PM -0700, Brandon High wrote:
On Wed, May 4,
On Wed, May 04, 2011 at 04:51:36PM -0700, Erik Trimble wrote:
On 5/4/2011 4:44 PM, Tim Cook wrote:
On Wed, May 4, 2011 at 6:36 PM, Erik Trimble erik.trim...@oracle.com
wrote:
On 5/4/2011 4:14 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 02:55:55PM
On Wed, May 4, 2011 at 4:36 PM, Erik Trimble erik.trim...@oracle.com wrote:
If so, I'm almost certain NetApp is doing post-write dedup. That way, the
strictly controlled max FlexVol size helps with keeping the resource limits
down, as it will be able to round-robin the post-write dedup to each
On Wed, May 4, 2011 at 6:51 PM, Erik Trimble erik.trim...@oracle.comwrote:
On 5/4/2011 4:44 PM, Tim Cook wrote:
On Wed, May 4, 2011 at 6:36 PM, Erik Trimble erik.trim...@oracle.comwrote:
On 5/4/2011 4:14 PM, Ray Van Dolson wrote:
On Wed, May 04, 2011 at 02:55:55PM -0700, Brandon High
On 5/4/2011 5:11 PM, Brandon High wrote:
On Wed, May 4, 2011 at 4:36 PM, Erik Trimbleerik.trim...@oracle.com wrote:
If so, I'm almost certain NetApp is doing post-write dedup. That way, the
strictly controlled max FlexVol size helps with keeping the resource limits
down, as it will be able to
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Erik Trimble
ZFS's problem is that it needs ALL the resouces for EACH pool ALL the
time, and can't really share them well if it expects to keep performance
from tanking... (no pun intended)
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Ray Van Dolson
Are any of you out there using dedupe ZFS file systems to store VMware
VMDK (or any VM tech. really)? Curious what recordsize you use and
what your hardware specs /
On Wed, May 4, 2011 at 10:15 PM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Erik Trimble
ZFS's problem is that it needs ALL the resouces for EACH pool ALL
On Wed, May 4, 2011 at 10:23 PM, Edward Ned Harvey
opensolarisisdeadlongliveopensola...@nedharvey.com wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Ray Van Dolson
Are any of you out there using dedupe ZFS file systems to store
From: Tim Cook [mailto:t...@cook.ms]
ZFS's problem is that it needs ALL the resouces for EACH pool ALL the
time, and can't really share them well if it expects to keep performance
from tanking... (no pun intended)
That's true, but on the flipside, if you don't have adequate resources
From: Tim Cook [mailto:t...@cook.ms]
That's patently false. VM images are the absolute best use-case for dedup
outside of backup workloads. I'm not sure who told you/where you got the
idea that VM images are not ripe for dedup, but it's wrong.
Well, I got that idea from this list. I said
35 matches
Mail list logo
