So 6.1+ (or is it 6.0+?) now does automatic downloading of firmware to disks which are inserted into the system that need a firmware update.
Are un-cached user reads still blocked by this process? Can disk firmware updates still take up to several minutes (this appears to still be the case)?
If yes to both questions above, is anyone concerned that the timing of this user downtime is linked to the actual swapping of the disk drive? That is, if I want to update firmware on a set of new spares at 2:00AM when users are mostly idle, I have to be on site and plugging them in one at a time at 2:00AM. Before I would attach the disks during the day and elect to run the slightly disruptive firmware update late at night from the comfort of my snuggly computer room at home.
Hopefully I'm missing some cool new feature that makes this concern moot. =)
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com
jkrueger@qualcomm.com (Jeffrey Krueger) writes:
So 6.1+ (or is it 6.0+?) now does automatic downloading of firmware to disks which are inserted into the system that need a firmware update.
Are un-cached user reads still blocked by this process? Can disk firmware updates still take up to several minutes (this appears to still be the case)?
I think things are better in this last respect than they were in ONTAP 5.x. That is based on the following experience.
I have an F740 with two shelves of ST118202FC disks. There is a firmware upgrade from NA26 to NA27 associated with moving from 6.0.1R3 to 6.1 (or to 6.0.2). I decided to update the firmware while still on 6.0.1R3, so as not to complicate the transition to 6.1.
I installed the new files in /etc/disk_fw and started by applying disk_fw_update to hot spares and an offline volume. This seemed to have no impact at all on service from the online volumes, which is definitely an improvement from 5.x. Then I applied disk_fw_update to everything. This certainly did cause some "NFS server not repsonding" messages from clients, but only towards the end of the spin-down/spin-up process.
Counts of NFS operations remained normal for some time after the spin-down started, which I presume was the F740 satisfying requests from data in memory. I speculated at the time that the normal 10-second CPs had been suspended, and that things only really seized up when the NVRAM got full. If that is right, then how long that would take would depend on the amount of file writing going on.
There wasn't any attempt by ONTAP to do the download's automatically; indeed, it said "Firmware is up-to-date on all disk drives" after the early disk_fw_update's in which most of the disks were still at NA26. But maybe that was a result of the way I had fooled it by updating /etc/disk_fw! Also, I didn't wait for the hourly process that updates the /etc/shm_* files, although I am unclear whether that actually has anything to do with the automatic firmware level checks.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
Chris Thompson -
Jeffrey Krueger