As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade?
Thanks.
Alex
alexei@cimedia.com wrote:
As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade?
Thanks.
Alex
I've upgraded our F330 running 4.3.4 and our F540 running 4.3.4 to 5.1D8 with no problems. You have to make sure you have the system requirements -> 128Mb RAM
and the firmware needs to be current ->1.9_i for F330's and 1.11_a for F540's. I think you may want to be a bit cautious if you're running CIFS.
Jeff
alexei alexei@cimedia.com writes:
As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade?
It's a simple upgrade, but here's my cautionary advice:
1. Upgrade one non-critical filer for at least a week prior to upgrading the rest (I actually stagger upgrades even more than that). Some problems can take a while to show up (like backup failures).
2. Don't downgrade. 5.x changes the filehandle format and some releases didn't behave correctly when downgrading from 5.x to 4.x. The result was that every client needed to be rebooted due to stale filehandle problems. I'm told this is fixed these days, but I still wouldn't trust it -- downgrading is undertested. (How many downgrades are there relative to the number of upgrades.)
My horror story is having to reboot 200+ Unix clients because we downgraded two filers from 5.x to 4.x. This was, according to someone at NetApp, a minor problem. If you don't mind rebooting your clients, this is a minor problem, but if you have to explain the rebooting to hundreds of engineers, it's something else.
This is another reason to only upgrade one filer at first.
3. Some options are per-volume. (For example, "options nosnapdir off" is now "vol options vol0 nosnapdir off".)
4. And obviously, read the docs, *upgrade the firmware* if necessary, have some emergency floppies on hand, etc.
I should mention that we are running 5.0.1 and 5.0.2 on all of our filers for some time now, and we are contemplating upgrading to 5.1.2. (The problem that caused us to downgrade from 5.x to 4.x has since been fixed in 5.x.)
Dan
- Some options are per-volume. (For example, "options nosnapdir off" is now "vol options vol0 nosnapdir off".)
Note that the per-volume options are persistent; their values are recorded in the file system "fsinfo block". Thus, for example, you don't have to update "/etc/rc" to put
vol options vol0 nosnapdir off
in. It'll *work* if you put it there, but it'll just overwrite the persistent setting on every boot, and probably overwrite it with the value it already has, on most boots.
"options nosnapdir off", and other options that are now per-volume, continue to work *if* you have a one-volume system, but "options XXX YYY" gets mapped to "vol options {one-and-only volume} XXX YYY", and is thus persistent.
As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade?
The only problem we've had is the result of subtle changes to the dump/restore commands.
The dump command changed slightly if you use the blocksize option. The restore command now outputs additional text that screwed up some of our restore scripts.
All in all - it's the most painless OS upgrade i've ever done.
Graham
As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade?
The only problem we've had is the result of subtle changes to the dump/restore commands.
The dump command changed slightly if you use the blocksize option. The restore command now outputs additional text that screwed up some of our restore scripts.
More specifically, in 5.1 (not 5.0) we don't allow tape record sizes greater than 64KB and we default to 63KB (rather than 10KB).
The upper bound was added because we added a new no-copy path from disk to tape for dump. Various tape driver limitations force us to stay to 64KB tape record sizes. We felt the performance benefit was worth the change. If you feel differently let us - David Yu:davidy@netapp.com(marketing), Grant Melvin:grant@netapp.com(manager) and me(some dude) know.
Don't worry, though, restore can handle the old block sizes that we allowed in previous releases.
The default was changed because: A) most people thought that our default already WAS 63KB B) Restore has always defaulted to 63KB.
The output change is that every restore output message is preceded by "RESTORE:" every dump message by "DUMP:". We added this to help us diagnose situations when a customer says "I got this error message." and it could be coming from dump, restore, or the fabulous new SnapCopy!
Hopefully Graham and everybody else haven't been/won't be terribly inconvenienced.
Stephen
-
alexei＠cimedia.com -
Daniel Quinlan -
Graham Knight -
guy＠netapp.com -
Jeff Giuliano, Agoura -
stephen＠netapp.com