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.edu> wrote:
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


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 | 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




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