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