Send in your Unix questions today! |
See additional Unix tips and tricks
If I'd had a stopwatch, I'd know for sure, but I'd swear that it took the field
engineer less than a minute to replace the batteries in my FC 3510 disk array.
The battery modules on these fiber channel devices are hot swappable, so there
was no need to shut anything down or to fail over either controller. Instead,
after the turning of two thumbscrews, the battery module with the expired
battery was extracted and a new one inserted in its place. Then the process
was completed for the second battery module.
I had only recently come to notice that the batteries had expired. Using the
sccli (StorEdge controller command line interface) command, I had noted the
expiration dates were well enough in the past that replacing them as soon as
possible was a good idea.
When I checked the batteries, the battery status information looked like this:
saturn# sccli
sccli> show battery-status
Upper Battery Type: 1
Upper Battery Manufacturing Date: Thu Mar 18 13:04:59 2004
Upper Battery Placed In Service: Thu Mar 18 13:04:59 2004
Upper Battery Expiration Date: Sat Mar 18 13:04:59 2006
Upper Battery Status: Expired
Lower Battery Type: 1
Lower Battery Manufacturing Date: Thu Mar 18 12:02:22 2004
Lower Battery Placed In Service: Thu Mar 18 12:02:22 2004
Lower Battery Expiration Date: Sat Mar 18 12:02:22 2006
Lower Battery Status: Expired
|
Had I tried to collect this information much earlier (if I'd even have thought
to check), it wouldn't have been available. It took a firmware upgrade on the
disk array and a newer sccli command to bring it to the level at which this
information could be collected and reported.
Once the new batteries were installed, the sccli command reported that the
new in service date had not been set.
saturn# sccli
sccli: could not set locale from environment; using default locale
sccli: selected device /dev/rdsk/c9t0d0s2 [SUN StorEdge 3510 SN#07E7E7]
sccli> show battery-status
sccli: Upper Battery: error: in service date not set in the battery
sccli: Lower Battery: error: in service date not set in the battery
|
I was able to update the service date by adding a -u (update) option to the
"show battery-status" command. The new date reflected the expiration date
for the new batteries (basically two years from the installation date).
sccli> show battery-status -u
|
The date 2007/ 9/ 7 will be stored as the In-Service Date of Upper Battery.
Are you sure that this date is correct? y
Upper Battery Type: 1
Upper Battery Manufacturing Date: Sat Jan 27 00:00:00 2007
Upper Battery Placed In Service: Fri Sep 7 16:50:35 2007
Upper Battery Expiration Date: Sun Sep 6 16:50:35 2009
Upper Battery Status: OK
|
The date 2007/ 9/ 7 will be stored as the In-Service Date of Lower Battery.
Are you sure that this date is correct? y
Lower Battery Type: 1
Lower Battery Manufacturing Date: Sat Apr 21 00:00:00 2007
Lower Battery Placed In Service: Fri Sep 7 16:51:12 2007
Lower Battery Expiration Date: Sun Sep 6 16:51:12 2009
Lower Battery Status: OK
|
The batteries are li-ion (lithium ion) batteries, designed to be recharged
hundreds of times, unlike their lithium counterparts which should not be
recharged. They have a greater energy storage capacity than NiCd (nickel
cadmium) and NiMH (nickel metal hydride) batteries.
While the expired batteries just removed from my disk array are not good
candidates for reuse (consider them to have been recharged hundreds of
times during their service lifetime in the disk array), they can be
recycled.
Li-ion batteries do not contain metallic lithium and are, thus, not subject
to the potential fire risk that lithium batteries incur when exposed to
moisture while they are corroding. At the same time, they contain little
retrievable metal. Any batteries should be disposed of properly and
recycled if at all possible, but these batteries pose less of a concern
than most battery types. If I don't have to drive a long distance to drop
these batteries at a recycling center, I'll make sure they wind their way
to the big melting pot.
