SnapMirror wouldn't work for what I've suggested as it is read-only asynch. A read/write synchronous mirror (i.e. RAID 4+1) would be required for what I suggested. Also, to avoid disruption to the client systems, the CIFS share name or NFS export could not be changed during the fw_update, so it would have to be the same set of data and not a snapmirror.

Thus even a synchronous snapmirror wouldn't work, unless you could make the snapmirror read/write, re-direct clients to the mirror on the fly without breaking the TCP session, and then reverse-synch once the disk_fw_update was done and put the clients back on the original disks. That'd be quite a trick!

Think 99.999% uptime, no disruption to clients for *ANYTHING*. Or at least nothing as common and (relatively) trivial as a firmware update.

I'd still say NetApp should look at ASUP logs and pre-flash replacement disks to the level appropriate for your ONTAP version before shipping them to you. That's probably a lot easier to do in the short term than my ambitious on-the-fly firmware update suggestion. :)

Hey--here's a technical question. SCSI RAID systems allow you to update the firmware on one disk without disruption I/O to the other disks. Is this possible on an FCAL loop? Or is the whole idea technically infeasible due to limitations in FCAL?

MD

-----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Monday, January 08, 2001 2:21 PM To: Tom "Mad Dog" Yergeau; 'Krause, Oliver'; toasters@mathworks.com Subject: Re: disk_fw_update issue with 840-5.3.7R2

It's too bad NetApp doesn't offer mirroring, since if you had mirrored

sets

this would be a real piece of cake. Just flash half a mirror while the other half served data.

Have you heard of something called SnapMirror?

Bruce