RAID card battery conditioning - "Battery failed (other than expired)"

OK, so if you log-in using the GUI, you get a warning telling you that battery conditioning is happening and that you shouldn't the server.
However, if you log-in over SSH, as you might, for instance, with a headless Xserve, you don't get that warning. And then, if you restart more than a certain number of times, for instance because you're installing all the software updates that the server has missed while it hasn't been switched on, you end up in the following state:
$ raidutil list status
Apple raidutil version: 1.2.0
General Status: Issues Found
Battery fault. See Battery Status below.
Battery Status: Battery failed (other than expired)
Controller #1: Hardware Version 2.00/Firmware E-1.3.2.0
Write Cache disabled
Plainly this is undesirable.
Does anyone know how to reset the battery state, preferably without having to pull the server out of its rack and disconnect the RAID card battery?
Also, since when was it in any way reasonable to tell a user that they can't shut their machine down for 24 hours? Even with a server, that's ridiculous - sometimes you just have to reboot.
Kind regards,
Alastair.

FWIW, I just filed rdar://7653429 about the fact that terminal users don't get any warning of this, and rdar://7653468 about the fact that battery conditioning shouldn't force sysadmins to keep their machine running for the next 24 hours (since they might really need to shut it down, right now).

Similar Messages

RAID Battery failed (other than expired)

hello,
I've not even 1yr old Mac Pro with MB535PL/XXX/RAID,
Logs say in RAID logs that: `Battery failed (code 0x#0 = 18)', hard to imagine that it is battery fault.
I would like to know if there is any known solution because hw support wants me to send whole Mac to them.
Please check screenshot for more RAID Utility logs.
http://dl.dropbox.com/u/11758451/raid_bat.png
TIA
BRGRDS
LVJ

Hi, this is my whole log since attaching the card.
Thursday, April 28, 2011 8:23:47 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, April 18, 2011 12:17:09 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Friday, April 15, 2011 12:31:04 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, March 28, 2011 8:52:28 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, March 27, 2011 1:40:53 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, March 14, 2011 11:24:20 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, March 13, 2011 5:41:10 PM Poland Time          Battery failed (code 0x#0 = 18)          critical
Sunday, March 13, 2011 5:41:22 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, March 7, 2011 4:34:36 PM Poland Time          Battery finished conditioning          informational
Monday, March 7, 2011 9:33:31 AM Poland Time          Battery started scheduled conditioning cycle (write cache disabled)          informational
Monday, March 7, 2011 8:14:19 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Saturday, March 5, 2011 8:44:39 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, February 27, 2011 7:48:08 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Wednesday, February 23, 2011 3:23:56 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, February 14, 2011 12:50:45 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, February 13, 2011 8:44:28 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Tuesday, February 8, 2011 11:23:02 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Friday, January 28, 2011 5:33:49 PM Poland Time          Battery failed (code 0x#0 = 18)          critical
Friday, January 28, 2011 5:33:48 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, January 24, 2011 10:50:30 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, January 17, 2011 11:59:31 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Thursday, January 6, 2011 4:11:33 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Wednesday, January 5, 2011 3:16:53 AM Poland Time          Battery failed (code 0x#0 = 18)          critical
Wednesday, January 5, 2011 3:17:02 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Friday, December 31, 2010 2:37:30 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Monday, December 20, 2010 4:03:06 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Wednesday, December 15, 2010 1:00:33 PM Poland Time          Write cache set to battery detect          informational
Wednesday, December 15, 2010 1:00:20 PM Poland Time          Write cache temporarily enabled          informational
Saturday, December 11, 2010 7:00:11 AM Poland Time          Battery failed (code 0x#0 = 18)          critical
Saturday, December 11, 2010 7:00:12 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Wednesday, December 1, 2010 11:17:34 PM Poland Time          Battery finished conditioning          informational
Wednesday, December 1, 2010 4:46:07 PM Poland Time          Battery started conditioning cycle (write cache disabled)          informational
Wednesday, December 1, 2010 4:22:20 PM Poland Time          Battery started conditioning cycle (write cache disabled)          informational
Tuesday, November 2, 2010 5:40:07 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Friday, October 29, 2010 9:35:08 AM Poland Time          Controller detected disorderly shutdown without battery backup          critical
Tuesday, November 2, 2010 5:19:11 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Friday, October 29, 2010 9:36:14 AM Poland Time          Write cache disabled due to insufficient battery charge          informational
Tuesday, October 19, 2010 12:58:09 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Tuesday, August 24, 2010 12:17:16 AM Poland Time          Battery finished conditioning          informational
Monday, August 23, 2010 5:11:50 PM Poland Time          Battery started scheduled conditioning cycle (write cache disabled)          informational
Wednesday, August 18, 2010 5:27:59 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, August 15, 2010 4:08:23 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Thursday, June 17, 2010 2:34:45 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Sunday, June 6, 2010 4:56:42 PM Poland Time          Write cache disabled due to insufficient battery charge          informational
Tuesday, May 25, 2010 5:11:29 PM Poland Time          Battery finished conditioning          informational
Tuesday, May 25, 2010 9:55:53 AM Poland Time          Battery started conditioning cycle (write cache disabled)          informational
Tuesday, February 23, 2010 1:04:33 PM Poland Time          Battery finished conditioning          informational
Tuesday, February 23, 2010 5:43:31 AM Poland Time          Battery started scheduled conditioning cycle (write cache disabled)          informational
Wednesday, November 25, 2009 5:43:30 AM Poland Time          Battery finished conditioning          informational
Tuesday, November 24, 2009 8:36:37 PM Poland Time          Write cache set to battery detect          informational
Tuesday, November 24, 2009 8:36:33 PM Poland Time          Write cache temporarily enabled          informational
Tuesday, November 24, 2009 8:36:30 PM Poland Time          Write cache set to battery detect          informational
Tuesday, November 24, 2009 8:36:18 PM Poland Time          Write cache temporarily enabled          informational
Tuesday, November 24, 2009 8:31:34 PM Poland Time          Created volume “R1V1” on RAID set “RS1”           informational
Tuesday, November 24, 2009 8:27:41 PM Poland Time          Created RAID set “RS1” (RAID 0)          informational
Tuesday, November 24, 2009 8:27:33 PM Poland Time          Deleted RAID set “JBODSet1”          informational
Tuesday, November 24, 2009 8:27:13 PM Poland Time          Deleted RAID set “JBODSet2”          informational
Tuesday, November 24, 2009 5:44:10 PM Poland Time          Battery started conditioning cycle (write cache disabled)          informational
Tuesday, November 24, 2009 1:38:34 PM Poland Time          Battery started conditioning cycle (write cache disabled)          informational

RAID Card reports ERROR: Battery failed (code 0x#0 = 18). Help!

Hi,
I have a MacPro computer that has 4 drives and Apple's Hardware RAID Card installed. It's been working great, but we first received notification via RAID Utility of the following error: 5/23/09:Battery failed (code 0x#0 = 18). We ignored it because we have a project in the works. Computer is degraded in performance, and we can tell. Restarted and got the notification: 5/24/09: Controller reports RAID System 72-hour battery reserve unavailable. System is configured to run without battery.
What shall we do to get this working again.
I reallly appreciate any and all pointers. Apples online help didn't appear to be operating correctly today, Sunday, May 25.
Thanks, and so long for now, TOM

Unfortunately, this is a widely known issue with Apple's raid card. I would get in touch with Apple as soon as possible; not online help, but actually call them.
http://forums.macrumors.com/showthread.php?t=439873
http://discussions.apple.com/thread.jspa?threadID=1405187&start=0&tstart=0

Apple Raid card fitted - expand command fails

Ladies and Gents,
Terminal and RAID n00b here.
4 x 750Gb drives in a Mac Pro with Raid card fitted.
Created R5 with 3 drives (messed up, expected 1.3Tb R5 - Got 698Gb + 670Gb spare space)..
Just wanted 1.3 Tb R5. Tried expand command from the user guide;
Terminal I/O below - any help please?
no-dns-yet:~ sn$ raidutil list volumeinfo
Volumes Status Raidset Type Size Comments
R3V1 Is Viable RS1 RAID 5 698.45GB Condition: Good
no-dns-yet:~ sn$ sudo raidutil modify volume --expand -n R3V1 -s 670.63GB
Unsupported by this version of the hardware/firmware.
Obliged for assistance please...
GUI screenshot here;
files.me.com/burtonboyz/2i0f74

Oops wrong forum - sorry

UCS C200 M2 - RAID Card R200-PL004 battery back-up

During the installation of a LSI 6G MegaRAID 9260-4i, I'm prompted with the statements "The battery is missing" and "Protect against data loss in the event of a server or power failure by providing emergency power to the cache memory."
Can anyone tell me if the battery back-up (R2XX-LBBU) for the LSI 6G MegaRAID 9260-4i (R200-PL004) is required or just simply a recommendation to prevent loss of data during a power failure? The ordering guide says "Battery Back-Up Option Available" so I'm assuming this is not a mandatory item for purchase.
Please advise.
Thanks,
C

Hello Chad,
BBU is optional.
C200 M2 technical spec sheet
http://www.cisco.com/en/US/prod/collateral/ps10265/ps10493/c200m2_lff_specsheet.pdf
Please check out STEP 4 section.
HTH
Padma

Apple Raid Card Battery Failed

Hey guys !
I have an early 2008 Mac Pro with a Raid Card and i get this message battery failure other than expired
actually i got this message again about an year or so back ... so yes it happened before ... Apple replaced my battery
Now im out of warranty coverage.
Questions are :
How does this affect my Raid Set ?
Can my Raid Set survive without the battery ?
If yes ... what are the downsides ?
What can i do to manage the situation without changing again the battery ?
Hope to get some advice soon on this matter
Thank you very much.
PS
Down below i pasted some specs for my machine
Mac Pro RAID Card:
PCI Slot:          Slot-4
Hardware Version:          1.00
Firmware Version:          M-2.0.5.5
Expansion ROM Version:          0018
Shutdown Status:          Normal shutdown
Write Cache Enabled:          No
Battery Info:
Firmware Revision:          1.0.2
First Installed:          1/1/01 2:16 AM
Last Date Conditioned:          2/24/12 3:47 PM
State:          Faulted Battery
Fault:          Battery failed (other than expired)
Status:
Charging:          No
Conditioning:          No
Connected:          Yes
Discharging:          No
Sufficient Charge:          No
Drives:
Bay 1:
Product ID:          ST3300655SS
Serial Number:          3LM35BGK00009827PBXY
Firmware Revision:          A005
Type:          SAS
SMART Status:          Unsupported
Capacity:          300 GB (299,999,999,488 bytes)
RAID Sets:          RS1
Status:
Assigned:          Yes
Failed:          No
Foreign:          No
Missing:          No
Reliable:          Yes
Roaming:          No
Spare:          No
Bay 2:
Product ID:          ST3300655SS
Serial Number:          3LM622YT00009923HP5Q
Firmware Revision:          A005
Type:          SAS
SMART Status:          Unsupported
Capacity:          300 GB (299,999,999,488 bytes)
RAID Sets:          RS1
Status:
Assigned:          Yes
Failed:          No
Foreign:          No
Missing:          No
Reliable:          Yes
Roaming:          No
Spare:          No
Bay 3:
Product ID:          ST3300655SS
Serial Number:          3LM2Y49T00009827PAZV
Firmware Revision:          A005
Type:          SAS
SMART Status:          Unsupported
Capacity:          300 GB (299,999,999,488 bytes)
RAID Sets:          R0-3
Status:
Assigned:          Yes
Failed:          No
Foreign:          No
Missing:          No
Reliable:          Yes
Roaming:          No
Spare:          No
RAID Sets:
R0-3:
RAID Level:          Enhanced JBOD
Capacity:          299.8 GB (299,798,364,160 bytes)
Available Capacity:          Zero KB
Drives:          Bay 3
Volumes:          Vol-R0-3
Status:          Viable (Good)
RS1:
RAID Level:          0
Capacity:          599.73 GB (599,730,946,048 bytes)
Available Capacity:          Zero KB
Drives:          Bay 1, Bay 2
Volumes:          R1V1
Status:          Viable (Good)
Volumes:
R1V1:
BSD Name:          disk1
Capacity:          599.73 GB (599,730,946,048 bytes)
Read Command Size:          2 MB
Read Ahead Margin:          16 MB
RAID Set:          RS1
Status:
Degraded:          No
Inited:          Yes
In Transition:          No
Viable:          Yes
Vol-R0-3:
BSD Name:          disk2
Capacity:          299.8 GB (299,798,364,160 bytes)
Read Command Size:          2 MB
Read Ahead Margin:          16 MB
RAID Set:          R0-3
Status:
Degraded:          No
Inited:          Yes
In Transition:          No
Viable:          Yes
Hardware Overview:
Model Name:          Mac Pro
Model Identifier:          MacPro3,1
Processor Name:          Quad-Core Intel Xeon
Processor Speed:          3.2 GHz
Number Of Processors:          2
Total Number Of Cores:          8
L2 Cache (per processor):          12 MB
Memory:          8 GB
Bus Speed:          1.6 GHz
Boot ROM Version:          MP31.006C.B05

The RAID card battery backs up the memory buffers on the card. These are needed for calculating the checksum blocks used in RAID 5 and similar schemes.
If you are not running RAID 5 or similar, you do not need the battery. For that matter, you do not need the RAID card, either (unless you are running SAS drives).

What's the difference in Apple RAID card battery error messages?

I have a Mac Pro with 2 quad core Intel Harpertown CPUs at 3.2GHz, and an Apple RAID card. RAID Utility shows that the battery failed but in my research, nobody explains the difference between "Battery failed (code 0x#0 = 17)" (which is what I have) and "Battery failed (code 0x#0 = 18)" or ""Battery failed (other than expired)" (the latter two are what everybody talks about) and what the code numbers mean. Speaking to a local AASP, they recommend that I just wait for a couple of days to see if it's doing the automatic 72-hour reconditioning operation since my Mac Pro is attached to a pretty hefty UPS (2200VA with nothing else attached) and power failures where I live are rare plus the write cache has been disabled so the RAID card is basically doing write-throughs at the moment. But curiosity about the various, different error codes and messages is getting the better of me. Thanks in advance.
Also, what's worrying me (since RAID Utility is so vague) is this entry I found under "Hardware RAID" in System Profiler:
Status:
Charging:          No
Conditioning:          No
Connected:          Yes
Discharging:          No
Sufficient Charge:          No

As an update to this, once I replaced the RAID card battery (which was an absolute nightmare--the writer of the instructions at Apple obviously had never done it for real nor seen it done since they omit a lot of important things), the problem went away. But I'm still intrigued about what the error codes mean.

Mac PRo with raid card shipped with drive not suitable for raid?

Hi all,
I ordered a Mac Pro with raid card and a 1TB hard drive. The drive which came in the computer was WDC WD1001FALS which is not a hard drive rated for raid usage. On Western Digital's site they suggest using WD1002FBYS.
Is the model WD1001FALS the correct drive which Apple ships although one ordered the raid card?

The WD 640GB Blue, and WD 1TB Black are the only drive options for the mac pro; that's what you choose.
The RE3 (or FBYS) is not an option sold through apple. Buying the raid card, is not going to change the drive.
On whether to use the RE3 over the Blacks, it depends on how you will be using it. From what I've heard, the Blacks are enterprise drives themselves; basically with just a less robust firmware (no TLER). If you will have the drives on 24/7 in a raid 5, then yes, RE3 will probably be better. If not, I think the black will suffice; note the blacks are GREAT drives by themselves anyway.
The apple raid card can connect to both SATA and SAS drives internally, however most times people buying the raid card want to use it for SAS drives. There are a lot more cheaper and possibly a lot more stable options then apple's raid card if you are looking to use SATA drives.
Check amug:
http://www.amug.org/
A common problem with the apple raid card is the battery:
http://store.apple.com/us/product/MA849Z/B?mco=NDc1ODczNw
Lastly about enterprise drives, truthfully I don't see the difference really. I have enterprise drives in a 8-drive raid5 config running 24/7 as a server. 2 drives died on me after about 4 months. To top it off, they died within 10 min of each other, crushing the raid to pieces. Granted they were Seagate ES.2's, it's understandable
The boot drive of the server is a stock desktop WD drive and running 24/7. It's been running for almost 4 years straight.

Help Required 2x Areca Raid Cards

Hi,
I have a Areca ARC-1680ix 16 port & a Areca ARC-1231ML 12 port
I wanted to know if it is possible to use both cards in one system, if so what is the best method.
I want to install this in a large Server Rack mount that has hot swapable bays.
Regards
Baz

That is up to the management software and firmware of the cards. If the firmware allows the cards to grab different resources then they both will initialize. If the management software allows you to manage both cards then your fine there. However if you are attempting to span a raid over both cards then that will require a contact with Areca. Intel cards have that option with an internal cable or atleast they did in the past. Normally a SAS expander card is a better solution than 2 raid cards currently.
Eric
ADK

Kernel panics whenever RAID card conditions battery

I have an early 2008 Mac Pro running 10.5.8, with an Apple RAID card with M-2.0.5.5 firmware. This has two Seagate Barracuda drives attached, formatted as RAID 0, and this RAID 0 is the OS drive.
Periodically, the RAID card conditions the battery. In the past I've been able to work while this was happening but, about three weeks ago, the conditioning started and the computer became completely unusable: there were kernel panics every minute or two and, on restarting, the report showed "AppleRAIDCard Controller Panic...". I eventually gave up and left it alone until the conditioning finished, and it's worked fine since.
This situation has just started again. It's only three weeks since the last conditioning; the gap was 6 weeks last time; and 12 weeks the time before that. Is the battery failing? Does that explain the constant AppleRAIDCard Controller-initiated kernel panics?
I didn't set up this computer and could happily live without RAID but this OS drive now has lots of software installed, much of which needed to be authorised by challenges/responses and explanations to software manufacturers as to why it was being reinstalled etc. Reformatting and reinstalling everything again would be a major PITA.
Is it possible to move the drives to a software RAID 0 without reformatting them? Is this likely to be less problematic than the Apple RAID card?
Thanks in advance,
Steve = : ^ )

I'd just like someone to comment on whether they think the battery alone could be responsible for unending KPs whenever the controller is conditioning the battery, or whether the card might be faulty.
I wonder about both points.
Did some searching, and there are several reports of other users with battery problems.
For some, the battery fixed the problem, for others, no remedy.
One example:
http://forums.macrumors.com/showthread.php?t=439873
For troubleshooting, identifying the source through eliminating causes related to the symptoms would be a reasonable approach.
Since the KP's occur only during battery conditioning, it places the most suspicion on the battery.
Personally, I see this as most telling.
Since you can't run without the battery, a replacement is the only way that I can think of to test the battery.
Other possibilities could be firmware related.
Is the card and the MP running the most current firmware?
If the firmware of the card and the MP are up to date, the battery, again, comes to the top of the suspect list.
And, of course, there is always the possibility that a component on card has failed.
Unfortunately, as with the battery, a replacement is needed to test.
I wouldn't move on this point until the battery theory were tested.
Not to dismiss the potential for software involvement, I'm wondering what are the OS X kexts that are involved with the processes leading to the KP's?
Logs in Console may provide some information.
Portions of the KP report immediately after the word "backtrace" also provide the best information.

Apple RAID Card - Battery failed (code 0x#0 = 18)

Hello,
Upon start up of the computer I get a message that says "The Apple RAID Card installed in your system requires your attention".
When I open up the RAID Utility I have messages like -
Battery failed (code 0x#0 = 18)
Write cache disabled due to insufficient Battery Charge
Can anyone explain what this means and what I should now do?
Do I need a new Battery and does this mean my RAID 5 isn't saving data correctly?
Thanks in advance for any assistance.
Kris

Hello
I have the same problem too:
Battery failed (code 0x#0 = 18)
or in my case, I am german: Die Batterie funktioniert nicht (Code 0x#0 = 18)
It happened the first time after one year and I replaced the battery. One year later it happened again and I replaced the battery. And one more year later again. This time I decided not to replace the battery.
I booted the system from the recovery media and started the the raid utility from there and it said: battery charging.
So I returned to my "normal" partition and it said: battery charging.
A few days later: Battery failed (code 0x#0 = 18)
I repeaded this several times, always with the same result.
I was quite sure that all the trouble resulted from a firmware bug.
So I did shut down my Mac, and removed my raid card. On the raid card I disconnected the battery and waited a few minutes and reconnected it. I reassembled all and started my Mac.
It is running now for more than a month without any further errors.

Xserve / internal RAID card / Battery Failed (code 0x#0 = 18)

Hi, RAID utility is reporting a battery problem. I have rebooted xserve once, the problem went away, the battery was charged but now I have the problem again.
The result is a disabled write cache, which reduces performance.
Changing the battery is quite a big effort, so I really would like to avoid this. Any ideas, what the problem might be and how to solve it?

Hi Lordlobby,
I've had this on 2, 2008 xserves. Started off randomly happening that the RAID card would report the same error code which wasn't down to the discharge cycle. It became worse so the battery was replaced and it's been fine since... It's about 15mins work to replace the battery..
Good luck
Beatle

Repair Apple RAID card battery

I have an Apple RAID card Mac Pro (Early 2009) RAID Card (top picture) with a bad battery. Unfortunately these batteries usually die after a few years and the replacement is not cheap. Looking on ebay, I can only get them from the US, but I live in Europe and it will cost me at least $150.
From what I suspect reading the case, the battery is a 3.7 V Lithium battery, probably with built-in electronics that I can perhaps get for $5 from China. Any soldering work is not a problem. If I can replace the digitizer of an iPad mini, I can probably replace a battery too.
The case of the battery looks like a regular aluminum box and the lit is probably just glued onto the battery. It's seems quite sturdy and would require some force to open. Has anyone ever opened an Apple Raid Card battery? I'm reluctant to apply much heat to open the case, though external heat might be ok. Any ideas? I'm aware of the risks.

To summarise the 'end of days' issue with RAID5 the problem is that with the much bigger size of hard disks now available and being used e.g. 4TB or even bigger, it takes so long to rebuild a RAID5 array when replacing a faulty drive that the chance of another drive failing during the rebuild is becoming more and more likely. This is actually made worse by the fact that a RAID rebuild causes a lot of activity and therefore 'stress' on the hard disks in order to do the rebuild process. It can take more than 24 hours to do a complete RAID5 rebuild and during all that time you are vulnerable to a complete failure.
RAID6 is a partial solution in that you start off with redundancy provided by two drives rather than RAID5 which has just one so RAID6 can survive two drive failures. It however only reduces the chances of having a complete RAID failure during a rebuild it does not eliminate it.
Standard RAID5 or RAID6 therefore is being increasingly viewed as having reached a brick wall.
For Enterprises i.e. those with lots of money you can just throw more drives at the problem e.g. RAID10. For the rest of us the hope is on new alternatives to RAID5. The one I am particularly excited about is BTRFS, this is a combination of both a RAID layer and a file-system layer, it is able to use file checksums from the file-system layer to spot and fix RAID issues and this is orders of magnitude more efficient than having to do a complete RAID resync/rebuild. This approach has two advantages, firstly it protects a problem described as 'bit rot' whereby a byte or block in a file can become corrupted, the checksums allow this to be detected and automatically fixed, the second is that it can do a rebuild of actual real data whereas a normal RAID rebuild rebuilds all blocks on a drive even empty ones.
BTRFS is still pre-release especially its equivalent of RAID5 and RAID6 but it is getting closer. (RAID 0 and 1 for BTRFS are already considered ready for use.)
ZFS is a similar 'new' file-system to BTRFS and at one point there was talk that Apple were going to switch to using ZFS but this no longer looks like happening. ZFS was a solution being developed and 'owned' by Sun Microsystems who are now part of Oracle. BTRFS is free open-source.
I personally hope that Apple at some point implement BTRFS.
There are some NAS manufacturers already implementing BTRFS however they are currently 'cheating'. NetGear for example use BTRFS on their current ReadyNAS OS 6.x models but rather than using a 'pure' BTRFS approach have a implemented BTRFS on top of a standard RAID5 system created by mdraid. They did this because as I mentioned above the official BTRFS RAID5/6 solution is not yet ready for real-world use. As a result you get some of the benefits of BTRFS like being more easily able to expand the size of a file-system, but you don't get the full checksum derived protection of BTRFS because it is not integrated to the RAID level. Thecus I believe have gone the same approach as NetGear. Synology and QNAP are still waiting for BTRFS to be 'finished' before implementing it.

Battery backed raid card

Hi,
I've been trying to determine whether there are any hardware raid cards with battery backed cache that are supported by Solaris 10 and offer online management and diagnostic utilities. The LSI Logic 320-2x (which is repackaged by Sun) is now supported by the lsimega driver, but there is little to no documentation for it (+broken links on sun.com).
Cards like this usually offer both BIOS-based configuration as well as online utilities. Some cards and the corresponding drivers may be managed using raidctl, but I cannot determine which cards and drivers.
If any body has links to documentation or personal experience that will enlighten me, it would be much appreciated.
Regards,
Michael

I was going to respond with my personal view, but this wikipedia page describes it adequately.
From http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks:
"With a software implementation, the operating system manages the disks of the array through the normal drive controller (IDE, SCSI, Fibre Channel or any other). With present CPU speeds, software RAID can be faster than hardware RAID, though at the cost of using CPU power which might be best used for other tasks. One major exception is where the hardware implementation of RAID incorporates a battery backed-up write cache and an application, like a database server. In this case, the hardware RAID implementation flushes the write cache to a secure storage to preserve data at a known point if there is a crash. The hardware approach is faster and limited instead by RAM speeds, the amount of cache and how fast it can flush the cache to disk. For this reason, battery-backed caching disk controllers are often recommended for high transaction rate database servers. In the same situation, the software solution is limited to no more flushes than the number of rotations or seeks per second of the drives. Another disadvantage of a pure software RAID is that, depending on the disk that fails and the boot arrangements in use, the computer may not be able to be rebooted until the array has been rebuilt."

MacPro Raid Card w/ SAS Drives is battery required?

We have a MacPro (early 2008) dual 2.8 Quad with Mac Raid Card and 4 300g SAS drives. The battery became an issue early on it was always showing low on start-ups. Now it shows failed. I am now running system with 3 drives striped raid 0. Is the battery required to be replaced? I like this system for the speed it gives us on short HD, using my original media as the back-up. I am a little out of my league with the SAS drives so any opperation tips would be a plus! Thanx in advance....

The RAID card allows for the use of SAS drives or for the use of RAID 5 (which requires checksum calculation on writes and for data re-creation after a failure).
The battery assures that the data will be held in the RAID card's RAM until it can be written to the drives, even if a power failure occurs just after the data are written to the card (but before they are re-written to the drives).
Not using that feature? You don't need the battery.
Not using RAID 5 or SAS drives? You don't need the Apple RAID card. Disk Utility can set up Striped or Mirrored RAID sets.

RAID card battery conditioning - "Battery failed (other than expired)"

Similar Messages

Maybe you are looking for