Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Netapp: toasters

de-dup of memory? (was Re: Snapvault slow on one specific volume?)

 

 

Netapp toasters RSS feed   Index | Next | Previous | View Threaded


tmerrill at mathworks

Nov 13, 2008, 9:03 AM

Post #1 of 4 (1191 views)
Permalink
de-dup of memory? (was Re: Snapvault slow on one specific volume?)

On Wed, 15 Oct 2008, Darren Sykes wrote:

> Iąd say it was probably the bug; in theory dedup should increase performance
> in that situation as the block would be stored in the cache and therefore we
> wouldnąt need to go to disk to get that data.

Is this true?

Is memory "de-dup'ed" as well? That is, when you access a file through
the cache, if it ends up at a de-dup'ed block, is it really the same
block in *memory*, too? Or, is the path through memory/cache unique
and only the final disk store de-dup'ed?

Until next time...

The MathWorks, Inc. 508-647-7000 x7792
3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX
tmerrill [at] mathworks http://www.mathworks.com
---


jeremy.page at gilbarco

Nov 13, 2008, 9:05 AM

Post #2 of 4 (1109 views)
Permalink
RE: de-dup of memory? (was Re: Snapvault slow on one specific volume?) [In reply to]

I don't know :)

In theory it should work. When you request data you're not requesting it from the disk, your asking for a specific block. If that block is in cache it should not matter if it's deduped (and pretending to be several blocks) or not.


-----Original Message-----
From: Todd C. Merrill [mailto:tmerrill [at] mathworks]
Sent: Thursday, November 13, 2008 12:04 PM
To: Darren Sykes
Cc: Glenn Walker; Page, Jeremy; toasters [at] mathworks
Subject: de-dup of memory? (was Re: Snapvault slow on one specific volume?)

On Wed, 15 Oct 2008, Darren Sykes wrote:

> Iąd say it was probably the bug; in theory dedup should increase performance
> in that situation as the block would be stored in the cache and therefore we
> wouldnąt need to go to disk to get that data.

Is this true?

Is memory "de-dup'ed" as well? That is, when you access a file through
the cache, if it ends up at a de-dup'ed block, is it really the same
block in *memory*, too? Or, is the path through memory/cache unique
and only the final disk store de-dup'ed?

Until next time...

The MathWorks, Inc. 508-647-7000 x7792
3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX
tmerrill [at] mathworks http://www.mathworks.com
---



Please be advised that this email may contain confidential information.
If you are not the intended recipient, please do not read, copy or
re-transmit this email. If you have received this email in error,
please notify us by email by replying to the sender and by telephone
(call us collect at +1 202-828-0850) and delete this message and any
attachments. Thank you in advance for your cooperation and assistance.

In addition, Danaher and its subsidiaries disclaim that the content of
this email constitutes an offer to enter into, or the acceptance of,
any
contract or agreement or any amendment thereto; provided that the
foregoing disclaimer does not invalidate the binding effect of any
digital or other electronic reproduction of a manual signature that is
included in any attachment to this email.


chrism at mochadata

Nov 13, 2008, 9:41 AM

Post #3 of 4 (1108 views)
Permalink
RE: de-dup of memory? (was Re: Snapvault slow on one specific volume?) [In reply to]

From what I understand the filer isn't smart enough to know that multiple reads are coming in to attack a deduplicated block so it will attack the disk for every read request. This can be alleviated through the use of PAM cards in the filer currently, otherwise I believe it is mostly "fixed" in 7.2.6 (before it was pulled) and the upcoming 7.3.1.

It's really pronounced in VMware environments if you test it with a boot storm (fire up a bunch of deduplicated VMs at once) or deploy VMs from a template.

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks] On Behalf Of Todd C. Merrill
Sent: Thursday, November 13, 2008 11:04 AM
To: Darren Sykes
Cc: Glenn Walker; Page, Jeremy; toasters [at] mathworks
Subject: de-dup of memory? (was Re: Snapvault slow on one specific volume?)

On Wed, 15 Oct 2008, Darren Sykes wrote:

> Iąd say it was probably the bug; in theory dedup should increase performance
> in that situation as the block would be stored in the cache and therefore we
> wouldnąt need to go to disk to get that data.

Is this true?

Is memory "de-dup'ed" as well? That is, when you access a file through
the cache, if it ends up at a de-dup'ed block, is it really the same
block in *memory*, too? Or, is the path through memory/cache unique
and only the final disk store de-dup'ed?

Until next time...

The MathWorks, Inc. 508-647-7000 x7792
3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX
tmerrill [at] mathworks http://www.mathworks.com
---


Darren.Sykes at csr

Nov 13, 2008, 2:34 PM

Post #4 of 4 (1101 views)
Permalink
RE: de-dup of memory? (was Re: Snapvault slow on one specific volume?) [In reply to]

No, not true (yet).

I was misinformed, though I do believe it's a planned feature. At the moment the filer's not bright enough to store the block once in cache.


________________________________

From: Page, Jeremy [mailto:jeremy.page [at] gilbarco]
Sent: Thu 11/13/2008 17:05
To: Todd C. Merrill; Darren Sykes
Cc: Glenn Walker; toasters [at] mathworks
Subject: RE: de-dup of memory? (was Re: Snapvault slow on one specific volume?)



I don't know :)

In theory it should work. When you request data you're not requesting it from the disk, your asking for a specific block. If that block is in cache it should not matter if it's deduped (and pretending to be several blocks) or not.


-----Original Message-----
From: Todd C. Merrill [mailto:tmerrill [at] mathworks]
Sent: Thursday, November 13, 2008 12:04 PM
To: Darren Sykes
Cc: Glenn Walker; Page, Jeremy; toasters [at] mathworks
Subject: de-dup of memory? (was Re: Snapvault slow on one specific volume?)

On Wed, 15 Oct 2008, Darren Sykes wrote:

> Iąd say it was probably the bug; in theory dedup should increase performance
> in that situation as the block would be stored in the cache and therefore we
> wouldnąt need to go to disk to get that data.

Is this true?

Is memory "de-dup'ed" as well? That is, when you access a file through
the cache, if it ends up at a de-dup'ed block, is it really the same
block in *memory*, too? Or, is the path through memory/cache unique
and only the final disk store de-dup'ed?

Until next time...

The MathWorks, Inc. 508-647-7000 x7792
3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX
tmerrill [at] mathworks http://www.mathworks.com <http://www.mathworks.com/>
---



Please be advised that this email may contain confidential information.
If you are not the intended recipient, please do not read, copy or
re-transmit this email. If you have received this email in error,
please notify us by email by replying to the sender and by telephone
(call us collect at +1 202-828-0850) and delete this message and any
attachments. Thank you in advance for your cooperation and assistance.

In addition, Danaher and its subsidiaries disclaim that the content of
this email constitutes an offer to enter into, or the acceptance of,
any
contract or agreement or any amendment thereto; provided that the
foregoing disclaimer does not invalidate the binding effect of any
digital or other electronic reproduction of a manual signature that is
included in any attachment to this email.


To report this email as spam click https://www.mailcontrol.com/sr/9!QLsXAQzo7TndxI!oX7UtTXwRoU2H8X2u0YC71a7uG!mS4n+IpEAvQOJ3QxhtWrURwikaZmT9jwq3xXRfv08Q== .

Netapp toasters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.