blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } Yes I did. If I want to and it reduces my costs by 20%, I want that OPTION. If you could run that across say 600PB of data, as one worlkload example for said 20%, you wouldn't? Even on dense sata only. I would want that option. Gaining even 10% for data at moderate rest for with nearly zero performance guarantees against it would be worth the week, two, or so of scanning. It's Netapp's job to make it viable and compete. Mine (ours) to guide them (and others)on what we all want.
Sent from Yahoo Mail for iPhone
On Friday, September 23, 2016, 3:45 PM, Michael Bergman michael.bergman@ericsson.com wrote:
On 2016-09-23 09:09, Jeffrey Mohler 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)
I'm not too surprised (w.r.t. Yahoo). I expect much the same for us here
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 [having to file migrate via protocol] fixed via a scanner/etc that reads and relays out the file based structure.
We = Yahoo? You've requested NetApp to implement a bg WAFL scanner which will runt through the whole FlexVol (vol by vol) and compact it? While this will prob be fine (-ish) for AFF I don't think that scanner will be pleasant, even viable, to run on HyA based systems (spinning disk). If they do this my hunch is it will be limited to run in AFF only...
/M
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters