If you don't mind sharing with the group the types of problems other than snapmirror that you're seeing after the upgrade from 5.3.x to 6.0.1R1. I'm planning to perform the migration from 5.3.x to 6.0.1R1 and would be interested to know the problems you're having with 6.0.1R1. Thanks.

Basically our setup is 2 F720's, snapmirrored.

8 BSDI Webservers, V3/UDP/32K/RO/SOFT ... 4 to each 720.

Since the upgrade to 6.0.1R1 the machines have ALOT of stuff blocking in a VMSTAT. The load on the BSDI has gone into the 400's!

When we had this type of problem on a Sun, we backed down to V2/8K and life was great. We've tried V2 and V3, no luck. 32K and 8K, no luck. Soft and hard, no luck. Haven't tried TCP... But the main contention is....IT WORKED BEFORE HAND FINE, WHY NOT NOW? Not like this is the first time we are bringing it up. With the Suns, it was the first time bringing it up.

The only other indication was we WERE getting alot of "nfs server not responding" when we had the filer with "nfs.uds.xfersize" of 32K, and the mount as 8k. Once we changed the filer to 8k and the mount to 8k , seems like we've stopped seeing that.

Ticket in with NetApp, and they are saying that the network stats on the filer look fine, but it could still be a network issue. I've checked the Cisco 2924 switch it goes into (HARDCODED for 100/Full) and it shows a few CRCs or Frames, but compared to the number of packets its pushing, its nothing.

Thinking we could reduce the load on the webservers by adding another, we put it in. It appears to only have made things WORSE. We bounce it back and forth between the 2 filers and could see it making matters worse. The filers each push around 17Mb/s right now, and poorly. They normally were doing 22Mb/s perfectly.

The BSDI webservers were never rebooted during this whole thing. Just the webserver stopped and the filesystem (Unfortunately, it seems forcibily) unmounted. We did reboot 1 system to see if it'd cure it, and it didn't.

We really had no say in doing this upgrade. These are colocated customer FILERS, with our network and BSDI servers. He wanted to put 72G disks on the filer, and 5.3.X that we were running didn't support it.

Now its limping, BADLY. We've turned monitoring on since sometimes 3 or 4 servers will get loads of 300 or 400. And now its in our lap to fix it.

Sorry if I rambled ...... You asked... 8-)

Tuc/TTSG Internet Services, Inc.

Peter

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Tuc Sent: Monday, February 05, 2001 1:01 PM To: Thomas.L.White@chase.com Cc: taob@risc.org; toasters@mathworks.com Subject: Re: SnapMirror 5.3.6R2 -> 6.0.1R1

...

in the upgrade to 6.0.1R1 it mentions that all snapshots have to be blown away before allowing snapmirror to run again. But this (as far as I know) refers ro upgrade source as well as

destination

...

Ihave not seen any comments re: Upgrading one side only.

ERRR?? Where did you see this?

We just upgraded 2 5.3.4RWHATEVER to 6.0.1R1 on Feb 1, and we were told that you had to do both in a snapmirror because of the version issues Brian found. We are having alot of problems with the filers and the systems since the upgrade, but are trying to work it out.

No one told us about deleting the previous snapshots....

Thanks, Tuc/TTSG Internet Services, Inc.

...

tw

Brian Tao taob@risc.org@mathworks.com on 02/05/2001 12:45:37 PM

Sent by: owner-toasters@mathworks.com

To: toasters@mathworks.com cc: Subject: SnapMirror 5.3.6R2 -> 6.0.1R1

Couldn't find any reference to this error message on NOW:

Sun Feb 4 23:47:00 EST [drp-na1: worker_thread:error]: snapmirror: Filesystem version mismatch for destination volume nocna1_vol0, reverting the version and aborting transfer. SnapMirror will retry until this revert is complete.

That appears on a destination F840 running 6.0.1R1.  Volume

/vol/nocna1_vol0 on the F840 is large enough and is marked offline. "snapmirror status" shows:

Source Dest Status 192.168.50.17:vol0 drp-na1:nocna1_vol0 Idle

Filer 192.168.50.17 is an F740 running 5.3.6R2.  It prints this to

syslog:

Sun Feb 4 23:29:18 EST [worker_thread]: snapmirror: Destination drp-na1 could not accept a complete transfer Sun Feb 4 23:49:18 EST last message repeated 20 times

What is this about filesystem versions?  Is the F840 doing

something about it on /vol/nocna1_vol0? How can I check on the progress of this revert operation?

I guess I should be asking:  are 5.3.x and 6.0.x snapmirrors

compatible? The 6.0 Data Protection Guide doesn't mention caveats or incompatibilities. -- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't"