Hi Jeff,

There is a thread on the RAID lost write scrub when upgrading to Ontap 8.1 or later:

https://forums.netapp.com/thread/30084

It's also described in the Netapp KB ID: 3013583 "What is RAID lost write protection?" This mentions:

"The only performance impact expected is that of scrub, which can be scheduled and stopped by the usual means (for more information, see the 'aggr scrub' man pages)."

You can delay this RLW upgrade by tuning the scrub policies to periods of lower usage and in your case stagger them across the aggregates.

I can't find references to it but even prior to 8.1 I noticed for a time after an Ontap upgrade there is an increase in disk and CPU activity while the Filer does background WAFL tasks post upgrade.

As the Netapp Upgrade Advisors suggest I always run a perf stat before an Ontap upgrade during a period when the Filer is under it's normal load so that I have something to compare with post upgrade.

If you are considering 8.1.2 I would take a look through the bugs fixed in the subsequent P releases (8.1.2P4 has just been released) as there are quite a few important fixes in these.

On a side note if you have multiprocessor Controllers the distribution of load across CPUs was improved dramatically from 7.x.x to 8.1 and above which should improve CPU utilization.

Regards Martin

-- View this message in context: http://network-appliance-toasters.10978.n7.nabble.com/Delaying-64-bit-aggreg... Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

Greetings,

I wanted to give an update of where things were with us and say thanks to everyone who replied on and off post.

1. We're going to go with the 8.1.2P4 release because we have large file writes/deletes and it is currently causing us problems. I had going to a release that is a week old, but it might be a couple more weeks before we can do the upgrade.

2. The RLW was one of the things I was thinking of for the issues after the upgrade. I also had a friend who did a similar upgrade (7.3.5 -> 8.1.2 to new 6280s) but used SM to migrate all the data ahead of time. When he released the relationships, everything got upgraded to 64 bit. That ran for a while which is why I thought there was an aggregate issue.

3. We don't use dedup on any of our filers so that won't be a problem, or any other issues related to it. For all the problems we had on various 7.x levels, it wasn't worth the single digit savings we got on most of our volumes.

4. I have been looking at Support Advisor and we have a PS type person who is supposed to help clarify things.

We have new 6290s to put in place, but that is a known full lab downtime. We're hoping to just do an OS upgrade on the existing hardware first, but we need to have the other hardware and a plan for it just in case something goes bad. If we are going to cause an unplanned outage we may as well do what we need to if it happens :-)

Thanks again for all the help and comments.

Jeff

On Wed, May 15, 2013 at 1:32 AM, Fletcher Cocquyt fcocquyt@stanford.eduwrote:

Also recommend disabling dedup prior to migrations/upgrades unless you like the dedup schedule (usually midnight) waking your on call sysadmins - we ran into bugs

see: http://www.gossamer-threads.com/lists/netapp/toasters/12815

Did you engage support and/or (upgrade advisor) - there are bound to be a few other issues going 7.3.5 to 8.1.2 independent of the 64 bit aggr issue(s).

Currently resolving a chassis HA vs node mode mismatch panic on a 2240-4 cluster.

Fletch.

On May 14, 2013, at 8:57 AM, Jeff Cleverley jeff.cleverley@avagotech.com wrote:

Andre,

I guess I need a different refresher. I seem to recall people doing upgrades and their systems being slow for an extended period of time immediately afterwards. I thought it was doing the 64 bit upgrade. Since that isn't the case, I need to try and figure out what was affecting the systems. I'll try a broader search of the mailing list and see what I can find.

Thanks,

Jeff

On Mon, May 13, 2013 at 6:25 PM, Clark, Andre < aclark@insightinvestments.com> wrote:

...

Jeff,****

---

32 to 64bit conversion doesn’t happen that way. The ways you’ll get a 32bit aggregate to go to a 64bit aggregate are:****

---

**a. **After upgrading to 8.1, adding additional spindles to the 32bit aggregate to go beyond the 16TB limit and, in the background, the 64bit conversion will start.****

**b. **A SnapMirror from a 32bit to 64bit aggregate and when the mirror relationship is broken, the 64bit conversion will start.****

---

If you are just doing an in-place upgrade to 8.1.2, the aggregate conversion process will not start.****

*Regards,*

*André M. Clark **| Sr. Consulting Engineer, Team Lead | Insight Integrated Systems http://www.insightintegrated.com/ | 917.388.8236*

*Tell me I will forget... Show me I may remember... Involve me I WILL UNDERSTAND!!!*

*Start by doing what's necessary, then what's possible, and suddenly you are doing the impossible!!!*****

---

---

---

*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Monday, May 13, 2013 20:12 *To:* Toasters@teaparty.net *Subject:* Delaying 64 bit aggregate upgrades****

---

Greetings,

Is there a way to go from 7.3.5 to 8.1.2 without having all the aggregates start doing automatic conversions to 64 bit?

Our current filers are getting hit pretty hard. I think the OS upgrade will help, but I'm afraid the aggregate upgrades will generate too much disk activity and slow things down for a day or two. We have ~9 aggregates per head that are 10T or larger. Most of these only have one volume in them. The shared ones have a few volumes with 40M+ inodes in use. If I can upgrade the aggregates selectively it will make it less noticeable to the users.

Thanks,

Jeff

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****

-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters