Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Thanks for pointing out the KB article. I was reading TR-4476 earlier and it looks like it may need an update. Unless I'm missing something, the table on page 40 only applies to pre-8.3.1 versions of ONTAP where postprocess compression is not supported. https://www.netapp.com/us/media/tr-4476.pdf
I now see that on page 32 it mentions support for the background compression scanner in 8.3.2 and later. A footnote on the table on page 40 would be helpful.
On Tue, Oct 16, 2018 at 4:04 PM Konnerth, Karl Karl.Konnerth@netapp.com wrote:
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
For the most part, running it post-processing doesn't make sense. You might as well compress the data as it arrives. The overhead is microscope to the point I've never heard of it being detectable.
Here's a detailed explanation of compressing and compacting old data: https://words.ofsteiner.com/2018/02/22/oracle-databases-and-efficiency/
Read it carefully. There's a complicated interaction between compression and thin provisioning. If you don't have the settings right, your savings could be invisible.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Konnerth, Karl Sent: Tuesday, October 16, 2018 16:04 To: Philbert Rupkins philbertrupkins@gmail.com; Toasters toasters@teaparty.net Subject: RE: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ 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
Our plan is to primarily stick to inline compression. The catch is there are several large deduped-but-not-compressed-volumes on 7-mode systems we still need to migrate. My understanding is incoming snapmirror data is not reduced inline.
I'm thinking about running post-process compression on each volume while on the 7-mode systems before they are transitioned to ONTAP9. On Tue, Oct 16, 2018 at 4:42 PM Steiner, Jeffrey Jeffrey.Steiner@netapp.com wrote:
For the most part, running it post-processing doesn't make sense. You might as well compress the data as it arrives. The overhead is microscope to the point I've never heard of it being detectable.
Here's a detailed explanation of compressing and compacting old data: https://words.ofsteiner.com/2018/02/22/oracle-databases-and-efficiency/
Read it carefully. There's a complicated interaction between compression and thin provisioning. If you don't have the settings right, your savings could be invisible.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Konnerth, Karl Sent: Tuesday, October 16, 2018 16:04 To: Philbert Rupkins philbertrupkins@gmail.com; Toasters toasters@teaparty.net Subject: RE: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ 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
Correct, inbound data isn't compressed as it arrives, unless you're using FLI. You actually can migrate LUN data from ONTAP to ONTAP using FLI if you wish.
I don't think adaptive compression is available in 7-mode, so you wouldn't be able to compress prior to migration. There's secondary compression in 7-mode, but you don’t' want that with any kind of actively changing dataset.
What is your migration plan? 7MTT or something else?
-----Original Message----- From: Philbert Rupkins philbertrupkins@gmail.com Sent: Tuesday, October 16, 2018 16:52 To: Steiner, Jeffrey Jeffrey.Steiner@netapp.com Cc: Konnerth, Karl Karl.Konnerth@netapp.com; Toasters toasters@teaparty.net Subject: Re: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Our plan is to primarily stick to inline compression. The catch is there are several large deduped-but-not-compressed-volumes on 7-mode systems we still need to migrate. My understanding is incoming snapmirror data is not reduced inline.
I'm thinking about running post-process compression on each volume while on the 7-mode systems before they are transitioned to ONTAP9. On Tue, Oct 16, 2018 at 4:42 PM Steiner, Jeffrey Jeffrey.Steiner@netapp.com wrote:
For the most part, running it post-processing doesn't make sense. You might as well compress the data as it arrives. The overhead is microscope to the point I've never heard of it being detectable.
Here's a detailed explanation of compressing and compacting old data: https://words.ofsteiner.com/2018/02/22/oracle-databases-and-efficiency /
Read it carefully. There's a complicated interaction between compression and thin provisioning. If you don't have the settings right, your savings could be invisible.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Konnerth, Karl Sent: Tuesday, October 16, 2018 16:04 To: Philbert Rupkins philbertrupkins@gmail.com; Toasters toasters@teaparty.net Subject: RE: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ 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
We're not using the 7MTT tool. We're just using snapmirror TDP relationships to bring the data over to new vservers. Cutting over manually. On Tue, Oct 16, 2018 at 4:57 PM Steiner, Jeffrey Jeffrey.Steiner@netapp.com wrote:
Correct, inbound data isn't compressed as it arrives, unless you're using FLI. You actually can migrate LUN data from ONTAP to ONTAP using FLI if you wish.
I don't think adaptive compression is available in 7-mode, so you wouldn't be able to compress prior to migration. There's secondary compression in 7-mode, but you don’t' want that with any kind of actively changing dataset.
What is your migration plan? 7MTT or something else?
-----Original Message----- From: Philbert Rupkins philbertrupkins@gmail.com Sent: Tuesday, October 16, 2018 16:52 To: Steiner, Jeffrey Jeffrey.Steiner@netapp.com Cc: Konnerth, Karl Karl.Konnerth@netapp.com; Toasters toasters@teaparty.net Subject: Re: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Our plan is to primarily stick to inline compression. The catch is there are several large deduped-but-not-compressed-volumes on 7-mode systems we still need to migrate. My understanding is incoming snapmirror data is not reduced inline.
I'm thinking about running post-process compression on each volume while on the 7-mode systems before they are transitioned to ONTAP9. On Tue, Oct 16, 2018 at 4:42 PM Steiner, Jeffrey Jeffrey.Steiner@netapp.com wrote:
For the most part, running it post-processing doesn't make sense. You might as well compress the data as it arrives. The overhead is microscope to the point I've never heard of it being detectable.
Here's a detailed explanation of compressing and compacting old data: https://words.ofsteiner.com/2018/02/22/oracle-databases-and-efficiency /
Read it carefully. There's a complicated interaction between compression and thin provisioning. If you don't have the settings right, your savings could be invisible.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Konnerth, Karl Sent: Tuesday, October 16, 2018 16:04 To: Philbert Rupkins philbertrupkins@gmail.com; Toasters toasters@teaparty.net Subject: RE: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ 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
Just read your article and the one question that popped up is the usefulness or need for enabling dedupe, either post or inline. Your article said “no” deduplication. Does that mean don’t use it anymore or just not with the Oracle DBs you were discussing in particular?
-- Scott s.eno@me.com
On Oct 16, 2018, at 5:42 PM, Steiner, Jeffrey Jeffrey.Steiner@netapp.com wrote:
For the most part, running it post-processing doesn't make sense. You might as well compress the data as it arrives. The overhead is microscope to the point I've never heard of it being detectable.
Here's a detailed explanation of compressing and compacting old data: https://words.ofsteiner.com/2018/02/22/oracle-databases-and-efficiency/
Read it carefully. There's a complicated interaction between compression and thin provisioning. If you don't have the settings right, your savings could be invisible.
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Konnerth, Karl Sent: Tuesday, October 16, 2018 16:04 To: Philbert Rupkins philbertrupkins@gmail.com; Toasters toasters@teaparty.net Subject: RE: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Phil,
NetApp does support running the background compression scanner on AFF volumes. Please see this KB article: https://kb.netapp.com/app/answers/answer_view/a_id/1030585
---Karl
-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Philbert Rupkins Sent: Tuesday, October 16, 2018 1:51 PM To: Toasters toasters@teaparty.net Subject: AFF Post Process Compression?
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Toasters,
I've come across several docs that make it clear that both secondary and adaptive post-process compression are not compatible with AFF systems. I have yet to find an explanation for this.
Does anybody know why? My best guess is it will shorten the life of the SSD's.
We have several large deduped-but-not-compressed volumes we're migrating from 8.1.4 7-Mode to AFF systems running ONTAP 9.2. I was hoping to run post-process compression on these volumes once cutover to the 9.2 system to reap additional savings.
I'm currently looking into enabling compression before cutting the volumes over to ONTAP9. However, each volume has 70+ snapshots associated with them and I see best practices for compression suggest removing as many snpashots as possible before running the post-process job.
Thank you, Phil _______________________________________________ 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