My understanding is that both are block based operations so it makes sense to me that the blocks would be put down on disk unchanged.  Perhaps it has something to do with the fact that you may want to reverse the snapmirror back to the system that presumably does not have compaction enabled or support the feature, so the blocks are left uncompacted?  If the vol move is within the same controller AFF the lack of backward compatibility is not a concern.  Just a though, I don't know. 

On Fri, Sep 23, 2016 at 10:57 AM, Francis Kim <fkim@berkcom.com> wrote:

Strange how compaction appears to work with vol move but not with snap mirror. 

.

On Sep 23, 2016, at 4:39 AM, Steiner, Jeffrey <Jeffrey.Steiner@netapp.com> wrote:

A vol-move operation will cause compaction to happen. I know it's not ideal but at least its internal. Obviously a scanner is preferred but functionally it would be a lot like a vol move. 

Likewise if you use FLI to import a LUN that will trigger all the efficiency features during the import. 

Sent from my mobile phone. 

On 23 Sep 2016, at 02:10, Jeffrey Mohler <jmohler@yahoo-inc.com> wrote:

Compaction in our testing can be good, really good...an additional 20% in many of our test data sets on top of everything else.  (SSET diagnosis)

However, there are limitations on how you get data into AFF to get compaction...IE, you cant snapmirror it.

It must transfer, as far as we're told today, via a host/file based migration.   Be thinking bout this when you consider an AFF migration.  It must be done outside on ONTAP.

We have pushed to get this fixed via a scanner/etc that reads and relays out the file based structure.

 

_________________________________

Jeff Mohler

Tech Yahoo, Storage Architect, Principal

(831)454-6712
YPAC Gold Member

Twitter: @PrincipalYahoo
CorpIM:  Hipchat & Iris

On Friday, September 23, 2016 1:53 AM, Mike Gossett <cmgossett@gmail.com> wrote:

my sales guy basically said the guarantee works as follows - they don't hit the 4:1 target, they buy you whatever amount of shelf\ssd required to makeup shortfall.  

The magic has to do with what they call "compaction" - writes <4KB (down to 512B/ea) are "compacted" into a single 4K block... this apparently adds to the std dedupe and compression they use.

On Thu, Sep 22, 2016 at 1:32 PM, jordan slingerland <jordan.slingerland@gmail.com> wrote:

Sales guys are promising me 4:1 dedup ratios on an AFF with ontap9. They say they grantee it.  I have specifically asked what stipulation.  In a VDI environment with linked clones, etc.  Sales guy tells me none and even specifically says they can dedup compressed video or audio (mp3) 4:1.

I have A LOT of trouble believing that.  So, 4:1 dedup guaranteed or what? 

Any comments welcome.

--Jordan

______________________________ _________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/ mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters