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@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Todd C. Merrill Sent: Thursday, November 13, 2008 11:04 AM To: Darren Sykes Cc: Glenn Walker; Page, Jeremy; toasters@mathworks.com 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@mathworks.com http://www.mathworks.com ---