Updating the firmware on Promise arrays is straight forward enough from the WebPAM. But what happens if a firmware update goes funky and you can’t get into the WebPAM any longer (ah, the joys of beta testing)? Well, you can always download an older firmware and reload it provided you can ssh or telnet into the host. Download from http://www.promise.com/support/download.aspx?m=93&region=en-global for your given model.
Then, you need the firmware accessible to the Promise chassis via tftp. A simple tftp GUI tool is available at http://ww2.unime.it/flr/tftpserver. Once configured, log into the Promise array and then use the ptiflash command to update the firmware. In the following command we’ll use the -s option to identify the IP address of our tftp server and then the -f option to identify the name of the file (note that I’ve shortened the ptif file for this X30 to be just fw.ptif so I don’t fat finger the multiple hyphens in a ridiculously long file name that I can’t autocomplete):
ptiflash -t -s 192.168.69.30 -f fw.ptif
If the server can’t access the file note that you have a tftp client binary that works much like the ftp binary built into OS X to test that you can access the server and the file from the IP address the X30 is using. If the file is accessible, when prompted to update the flash, enter y and press enter.
The update process is going to take about 15 to 20 minutes. If running the latest versions of the X30 firmware I recommend using Firefox.

If you are installing a Vtrak from Apple on Microsoft Windows you can download the drivers from Promise here:
http://www.promise.com/support/download/download_eng.asp
Having said this, you can use the Promise drivers or generic drivers if you’re using the Promise as targets and connecting to those LUNs via StorNext that are managed by Xsan. The reason for this is that StorNext will manage the LUNs. To see the LUNs, check Windows Device Manager.

We’ve been noticing since the last Promise firmware that the battery is scheduled to do a reconditioning every other month, on the 1st of that month. May 1st triggered a number of recondition events, starting at 2am and seeming to take about 12 to 24 hours to drain and recharge. When the RAID drains the battery it sets off an alarm, which can be, er, alarming if you’re in the data center. Also, when the hold-time dips the write policy automatically sets to write-thru, which can be changed to Disable Adaptive Write Cache to retain the write-back setting even when the battery drains.
No matter the settings that are used, we’ve found that performance will suffer during a reconditioning event. Therefore, it might make sense to schedule them on weekends, or whenever your organizations requirements allow for reconditioning. However, it is not prudent to outright disable the reconditioning, although it is debatable whether or not 60 day intervals is required for most environments.