Alex Hopmann’s Blog

There are currently 64 responses to “Silicon Image SATARAID5 and Reboots”

Why not let us know what you think by adding your own comment! Your opinion is as valid as anyone elses, so come on... let us know what you think.

1. 1 On August 12th, 2008, Jason said:

   Are you still experiencing the issue noted in your post? I’m considering picking up the same model, and am curious to see if you’ve found a workaround. It looks like a solid enclosure overall.

2. 2 On August 15th, 2008, Alex said:

   So far I am still experiencing the same problem although rebuilds appear faster with the newest driver update. The enclosure seems great and the eSATA controller hardware also seems fine, but the RAID5 software thing just has this stupid issue.

3. 3 On August 31st, 2008, Aaron said:

   Hey guys, having the same problem here as well. Good to see I’m not alone. The biggest thing I’m concerned is that I have this mass storage device acting as my archive for my Media Center and I have the thing on a bi-weekly reboot for refresh performance. The concern is that should I have a drive go down and a reboot occurs before I can replace and rebuild the drive, what happens? As I’m sure you guys know, a RAID 5 problem beyond one drive is pretty much critical causing total data loss.

   Anyway, that’s just my thoughts, I hope someone finds a solution or that Silicon Image is paying attention to this. Should this result in data loss, I’ll seriously consider boycotting all SI products in the future. A RAID 5 system, even external, should not be suffering from a rebuild issue everytime a normal shutdown or reboot is triggered in the OS. How else is one supposed to disconnect and shutdown or reboot properly if not from the normal proceedures?

   Good luck to everyone else having this trouble.

4. 4 On December 18th, 2008, Bart Hermans said:

   Same problem here too.
   Configuration :
   4x Lindy eSata Quad enclosure in RAID0 (16 disks=16TB)
   RAID10 over the 4 boxen.
   8TB disk visible in Windows 2008.
   Rebuilds in 15 minutes after every reboot.

   Problem not seen with 1 disk per channel.

   A solution yet ?

5. 5 On December 18th, 2008, Alex said:

   No solution with the SATARAID5 yet. What I’ve done is ditched using their RAID and I still use their hardware just in pass-through mode. I’m using Windows Home Server now and will post about that soon.

6. 6 On January 4th, 2009, Sid said:

   I have a similar problem - I have 3 (5 drive) replicators attached via a 4 port Silicon Imaging 3124 card. One replicator is setup for pass through, a second replicator is setup w/ 2 RAID0 raid groups and the third replicator is in a RAID5 config. Upon every reboot my RAID5 array has to restore redundancy. It looks like I’m losing parity upon shutdown. The RAID0 groups are fine (no parity - so no rebuild). The good news is parity only takes 15 to 20 mins to rebuild but I’m concerned that at some point I may end up with a corrupt array. This kind of thing can sometimes lead to corrupt file permissions preventing file access and ownership changes… I’m running MAC OSX 10.5.6 using the SATARAID5 manager v1.5.3.0

   I’ve looked online but can find an updated version of sataraid5 manager.

7. 7 On January 5th, 2009, Danny said:

   SATARAID5 - Silicon Image Configuration 3124/3726

   * X86 - Windows 2003 R2
   * PCI SiI3124 2 port E-Sata & 2 port SATA Controller
   * DATOptic 1U 5 SATA disc Enclosure with SiI3726 (SATA II Port Multiplier)
   * Silicon SiI 3124 SoftRaid 5 Controller Driver version 1.5.11.0
   * Windows application SATARAID5 version 1.5.3.0 “Parity RAID 5″ configuration.

   How do you properly shutdown the RAID before you shutdown the OS?

   I’m trying to avoid having the RAID rebuild itself everytime on startup?

   I read in the document about disconnecting via the task bar “Remove Hardware Safely” / Eject but I don’t see that icon in my task bar.

   Device Manager
   * Silicon SiI 3124 SoftRaid 5 Controller
   Should I use “Enable” or “Disable” to do a proper shutdown?

   Has anybody figured out how to shutdown the RAID properly?

8. 8 On January 21st, 2009, Doug said:

   My Silicon Image 3124 based controller does the same thing. After a reboot it says the RAID was not shutdown properly, the task in the Task Summary say “Restore Redundancy”, and it takes from 3 to 15 minutes to rebuild. Does anyone have a solution to fix this?

9. 9 On January 21st, 2009, Scott said:

   I have the same problem running Windows Home Server and a Sans Digital TR4M esata case with Silicon Image 3132r5 controller. I’m running 4 Seagate 1TB drives in Raid 5 and they have to restore redundancy after every reboot. I’ve tried recreating the raid, reinstalling drivers and even updating the bios on the Silicon Image card with no luck. I’ve even “safely removed Device” and it still ran through the restore redundancy on reboot. Any answers yet?

10. 10 On February 3rd, 2009, Ken said:

    Same problem w/ my G4 MDD w/ a Norco 4618 pci-x card w/ (4) WD ‘Green’ drives.

    Array bombs every time there’s a reboot or shutdown. Takes about 16 hours to rebuild (4) 1 Tb drives in Raid 5. That sucks. I predict this thing will eventually crash and not recover.

    Next Raid card will be a Highpoint. Better hardware and better software.

11. 11 On February 27th, 2009, JIm said:

    Hi. I have the same problem. 2x Seagate 320G in raid 1 config. and running directly off a sil3124 card. Using XP pro sp3. Worked fine for weeks then claimed windows not shut down properly, goes into synk mode on startup and stays there. when conplete it restarts sync mode. Driving me nuts. it would seem that the raid5 software is the problem not the hardware.
    I used the sil card as I had always had good service from a sata1 card from sil (different software) and preferred them over the native amd raid built into the mobo. The reason being a restore using acronis splits the drives and then requires a rebuild (acronis uses an old incompatible linux) nothing wrong with the AMD raid my 2 samsung 1T are running on AMD raid well.
    Any site of a solution yet?

12. 12 On March 24th, 2009, JokerA said:

    The same problem…
    Always [Restore Redundancy] after reboot
    Silicon Image 3114 PCI Card
    OS: Windows 2003 R2 SP2
    3114 BIOS: 5.4.03
    Driver: 1.5.15.0 or Windows update(Newer driver)
    HardDisk: WD 1TB x 4 to Raid5

    Windows screen image:
    http://jokera.mrs3.com/pg/albums/userpics/0/%E6%95%99%E5%AD%B8%E7%94%A8/MWSnap_20090325_111921.png

    Maybe…It doesn’t support so large single disk?
    (See the capacity 74706500)

13. 13 On April 18th, 2009, Steve said:

    I’m having the same problems on a Mac with OS10. Set up 4 1TB drives as Raid 5

14. 14 On May 13th, 2009, Bart Hermans said:

    Now we’re using the Lindy Sata-I Quad enclosures separate in RAID10 (4×1TB) for a while and they are working well.
    The Lindy Quad port RAID5 controller is connected to four Lindy Sata-I Quad enclosures = 4 disks of 1.8TB

    But now we bought new Lindy Sata-II Quad enclosures to get higher bus speed (eSATA and USB) but that really sucks. The recommended RAID-10 1TB Samsung disks configuration (RAID with DIP switches) is always rebuilding and never working. Great stuff. Never buy it!

15. 15 On May 13th, 2009, FireWire said:

    Why you guys are using SOFTWARE RAID5 is beyond me.

    DATOptic offers this great 5x Drive RAID5 - eBOX-R5, I was skeptical about this, but now I’m very please, it’s R/W over 200MB/sec

16. 16 On May 30th, 2009, Mike said:

    From the SATARAID5 User Guide v1.40:

    A known problem with some versions of Microsoft Windows may cause an unnecessary Parity Rebuild operation following hibernation. To address this issue, please apply the patch available from Microsoft at http://support.microsoft.com/?kbid=902853

    Hope this helps!

17. 17 On June 9th, 2009, Steve said:

    Has anyone found a solution to this problem? I’m having the same thing with an Edge10 eSATA DAS device and Vista 32bit.

    Thanks

18. 18 On June 9th, 2009, Alex said:

    Steve- the comment #16 suggests there is a patch from Microsoft that can help solve the problem. The patch only references Win2k3 server + WinXP, so I’m not sure how it impacts Vista. Frankly I gave up on using the Raid aspect of my Silicon Image eSATA device and am using it for pass-through drives (Home Server at the moment).

19. 19 On June 9th, 2009, Steve said:

    Thanks Alex. I checked the patch but it doesn’t seem that relevant. I’ve found a few other sites reporting this problem but no-one with a fix. I’ll stick with it since my reboots are infrequent and at least my data’s safe from single drive failure. I’ve asked my vendor but not had a response yet - I might ask them to contact Sil since I can’t do that myself. Regards, Steve

20. 20 On June 12th, 2009, Jim said:

    This seems to be a big prob. Have amd 64bit system vista64 and sil3124 with 2 drives mirrored. Get same issue on shutdown and startup causes a rebuild(not all the time). I thought at first it was the amd. If they fixed windows xp to solve the problem why not fix vista to solve the same thing. BUT, I note MAC has same problem. point finger at Silicon image?
    All the best
    Jim

21. 21 On July 15th, 2009, Jamie said:

    I have updated news. I think this has to do with the initial configuration of the RAID and how it’s set up.

    Here’s why: I have 2 RAIDS, both 5 drives, all with exactly the same models of hardware, attached to the same Sil3132r5 card. ONE of them reboots and rebuilds - the other does not…

    The two RAIDs were set up about 6 months apart (both while running Vista64). The first RAID, let’s call it RAIDa, had this problem, and I sat through rebuilds a few times, but eventually I decided to reformat and ran it for a short time as pass throughs. Later, after recreating the RAID group on top of the preformatted drives, the problem seemed to go away.

    Now with the new RAID, RAIDb, I set it up just like the old RAID, going straight to Parity Raid from initialization. Again the problem. I’m now in the process of resetting this RAID to pass-throughs, and then I’ll see if the problem goes away in a few days.

    Hope this helps. Anyone else find a potential solution?

22. 22 On August 15th, 2009, Stuart said:

    I thought I was alone with this problem.
    I have an Edgestore DAS401 RAID 5 configuration using 4 Hitachi HDt721010SLA350 1TB disks (Orignally took 34 hours to create RAID) running under Windows Vista Business 32-bit. I intend to move to Windows7 64 bit when its available.
    I have tried shutting the RAID down via the Safely Remove Hardware button on the task bar (’Safely Remove SiImage SCSI Disk Device’ selected) and it does not make a difference. It still runs the Restore Redundancy after each reboot. I have also noted if you do a couple of quick reboots (Common under Windows) the amount needing to be restored increases.
    There must be a way of shutting the device down correctly.

23. 23 On August 17th, 2009, Geeve said:

    Hi guys,

    Apparently the Windows Search indexer writes to the disk during shutdown and causes corruption which makes the RAID array want to rebuild everytime you reboot…

    Disable the Indexing Service and see if it works…

24. 24 On August 26th, 2009, Gabe said:

    Same issue on SIL3132 w/Vista 32bit. Indexing service is always off.

25. 25 On October 11th, 2009, Dave said:

    Partially similar result under Windows 7 - built a new array of 5×1TB drives using Sil3132 controller. When PC reboots, SATARAID5 software reports a warning that the “group” was not shut down properly and then begins the operation to restore redundancy. A second array (built previously under a different Sil3132 controller) is also attached to this same controller and it reboots with no error. So one array reports an error on reboot and the second one doesn’t.

26. 26 On October 22nd, 2009, Steve said:

    Any updates on this issue? Anyone find the magic combination if initialization to keep it from restoring redundancy on reboots? I have 4 1TB drives in raid 5 on a sil 3124 card in Win7 and can’t keep it from “restoring”. I don’t want to lose a 1000GB of space to move to raid 0+1….

27. 27 On October 28th, 2009, Chadd said:

    Managed to solve the problem by going to pass-thru mode, converting each disk to MBR and then back to GPT again, formatting each disk, and then disabling pass-thru and re-creating the raid.

    Makes me wonder if the problem is caused by different disks having different partition styles when the raid array is created.

    I did this using sil3132 under windows server 2008 and 5 1000GB drives.

28. 28 On November 22nd, 2009, Aaron said:

    Chadd, how did you disable the pass-thru, or did the pass-thru become disabled when you created the array? After running through the menu options I don’t see an choice to disable pass-thru. It seems after running the same series of steps you have listed, I see the raid build in the manager and of course windows (2003 Server) lists the drives as a single unit however with two partitions (931.39 Gb and 1863.02 GB - using 4 1 TB drives). i haven’t rebooted yet as the raid build is still on its way. Any input is greatly appreciated.

29. 29 On November 28th, 2009, Sagi said:

    I have the same issue with the restore redundancy after reboot on the sil3132 and 4x 1TB drives.

    I have tried following the recommendations here, converted them all to pass-thru converted to MBR then back to GPT, formatted and rebuilt the raid drive. still - same issue. Can’t seem to find a way to fix it.

    Any help will be appreciated.

30. 30 On December 2nd, 2009, kids said:

    “RESTORE REDUNDANCY” task summary mine took haft a day to complete about more than 113% shows on progress (4×500gb sil3114 softsaid SATARAID5 windows xp)i thought it wont stop but it did (and the legacy raid group yellow it turns to green)

    hope mine it works …have you try wait till it complete?

31. 31 On December 6th, 2009, Tommy said:

    So there’s no simple solution to this? I’m using the San Digital TR4M-B|TR4M (Silicon Image Sil3132r controller) with three Barracuda 1.5TB HDD in RAID-5 in Windows 7 64bit. It took me over 48 hours to build the raid 5, and probably another another 48 hours to do a full format. I rebooted after the format was done and now it’s telling me that it’s going to take another 48 hours to “Restore Redundancy”.

    Forget that!!! I’m not going through this crap every time I turn on my computer. I’ve Googled this issue like crazy and it seems that this is the only site that has some information on it.

    Looks like I’ll be using RAID-1 instead. I really need the redundancy.

    I want to give what Chadd suggested a try, but I can’t go through another 48 hours to only be disappointed. Screw it! Maybe I’ll invest in a real controller.

32. 32 On December 17th, 2009, DK said:

    I’m glad finally to have found folks discussing this issue. My first array didn’t have this issue, but upgrading to new disks, I now have it every time. Windows 2003 SP2, Norco enclosure. And I’m not even using RAID5 — I’m using RAID1 (I’ve found RAID5 is too slow with the SI chip). I second nearly-identical controller/enclosure/array on another box does not have this issue. I can’t find any discrepancy between them.

33. 33 On December 17th, 2009, DK said:

    I’m glad finally to have found folks discussing this issue. My first array didn’t have the reboot rebuild problem, but after upgrading to new disks, I now have it every time. Windows 2003 SP2, Norco enclosure. I’m using RAID10 (I’ve found RAID5 is too slow with the SI chip). A second nearly-identical controller/enclosure/array/server config does not have this issue. I can’t find any discrepancy between them.

    (Edited)

34. 34 On January 3rd, 2010, Steve said:

    A Workaround that worked for me!

    I believe the problem is related to the checkpointing option selected at RAID group creation. With ‘advanced options’ enabled, I had checkpointing set at the default ON position when I created the RAID group.

    I have recreated my RAID groups on both arrays (I have two with same problem) setting the checkpoint option to OFF. Both units now shut down tidy and don’t do a restore redundancy on boot / power up.

    Thanks to Chadd (above) as it was while I was trying his suggestion (didn’t work for me) that I decided to experiment and found the checkpointing workaround.

    The manual says I’ll get slightly better performance without checkpointing but longer recovery times from power failure. Easy decision for me since I have a UPS.

    One thing I noticed that was unexpected was that having deleted a RAID group and then created again with same settings bar the checkpointing option, my data was not erased. I had copied it away expecting to loose what was on the array. Highly recommend you backup the data anyway.

    This workaround worked for me, if it works for you please let us know.

35. 35 On January 6th, 2010, Nate said:

    Steve, seems like you’ve found the fix. Disabling checkpointing resolves the issue. Great find. Thanks.
    I have two 5 drive arrays with 400Gb drives in them and came across this problem when i upgraded one of the arrays to 1Tb drives.

    Ammusingly i also had a similar experience in that when i deleted and recreated the Raid Group the original data was still conveniently there. Though I did a backup beforehand just in case.

    The recovery/raid creation time with checkpointing disabled is definately slower but data writes and reads are very noticeably faster. Raid group creation for a 5TB array was around 35hrs whereas with checkpointing enabled it was 22hrs. Since my system rarely needs to perform a recovery this shouldnt be a problem.

    Just as a note for everyone, you need to enable Advanced Raid Options in the Array Manager configuration window before you will see the Checkpointing option during the Raid Group creation process.

    Glad i stumbled across this thread. Silicon Image support was useless. My only worry is that their current drivers for the Sil3124 cards are over 3 years old unless you are running Windows 7. I wonder how much effort they are putting into this product. May consider another product such as Highpoint in the future.

36. 36 On January 6th, 2010, Nate said:

    I also just back from DatOptic, the manufacturer of my eSata Drive Enclosure. They believe there is a bug with the use of large disks due to the RAID data not being written to the volume before power down.

    They suggest the following although i prefer Steve’s checkpointing fix above:

    For now please use this utility to remove the raid before shut-down the system http://mt-naka.com/hotswap/index_enu.htm

    Good luck!!

37. 37 On January 10th, 2010, KBeee said:

    Thanks Steve!
    Worked for me too.
    It’s been driving me mad but thanks to you it’s now working properly.

38. 38 On January 10th, 2010, KBeee said:

    I’ll add some details, as it might help others -
    Edge10 DAS501t 5 X 2TB Hitachi HDD in Raid 5
    Silicon Image 3132 PCIe card
    SI BIOS r7.7.0.2
    SI driver 1.5.19
    SI Management software SiL31342r5 1.5.19
    Motherboard Nvidia SLI 680i with P33 BIOS
    OS Windows 7 Home Premium 32bit

    On a side note, I found that if you need to create an array, or if the array needs to rebuild parity, then running a media player in the background halves the time it takes. I was using Media Player Classic Home Cinema, and it got my rebuild time down from 52 hours to 24 hours.

39. 39 On January 15th, 2010, Vernon said:

    I tried the workaround method and it worked for me too!!
    No more reoccurring restore redundancy on boot/power up

    Thanks Steve

40. 40 On January 23rd, 2010, Mike said:

    I saw this technical tip on the Silicon Image website and I’m wondering if enabling the write cache is similar to Steve’s suggestion of disabling checkpointing. The advantages and drawbacks look similar.

    SiI3xxx Write Cache Configuration
    http://www.siliconimage.com/docs/SII-TT-0021B.pdf

    I’ve got two 5TB arrays with a lot of data on them and I’m a bit apprehensive about deleting and recreating the RAID groups to disable checkponting. I’ve got backups but even so, it will take me several days to recreate the arrays and restore the data if I lose it. I thought that when a RAID group is created it automatically re-initializes the array and clears any pre-exisitng data.

    On the other hand, enabling the write cache just looks like a regsitry change.

    Comments anyone?

41. 41 On January 28th, 2010, Steve said:

    Hi Mike,

    Having read the tip (good find by the way) you will need to disable the write cache rather than enable it(which is the default).

    My advice would be to try the registry change first and see if that sorts you. If not, head for a raid group delete and recreate.

    Both Nate and I found that our data was not erased when we deleted and recreated the groups with the checkpointing off. Definately back yours up but you may save yourself a restore.

42. 42 On January 28th, 2010, Steve said:

    P.S. Took me best part of 5 days of data shuffling to sort mine, I’d have tried the reg fix first myself.

43. 43 On February 10th, 2010, Mike said:

    Thanks for the feedback Steve.

    I created a registry entry as described in the Silicon Image technical tip to disable the write cache and rebooted several times over the course of 2 weeks. After each reboot both of my arrays started a restore redundancy task the same as they did before.

    This is the registry entry I created:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Si3124r5\ProblemDevices\

    “WDC WD15EADS” = “DisableWriteCache”

    After creating this entry and rebooting I used the “Silicon Image SATA Controllers” control panel applet to confirm that the write cache on each of my 10 WD15EADS drives was disabled.

    Disabling the write cache also had the effect of reducing write performance from around 16MB/sec (which wasn’t all that fast to start with) to around 4MB/sec. Read performance did not appear to be affected.

    So, apparently this isn’t the fix. I’m going to try disabling checkpointing on one array and leave the second array unchanged as a control. I’ll post my results.

44. 44 On February 10th, 2010, Jeff said:

    Disabling checkpointing seems to be the magic fix.

    I’ve just built a 10 disk data store using 1 port multiplers (a third PM and 5 more disks still to be fitted)

    I’m running a RAID5 over 5 disks and had the same issue when shutting down.

    I have rebuilt the RAID and disabled checkpointing and now all is fine - as long as I shut the computer down BEFORE switching off the RAID power, thought I’d try that for testing…..that was 5 hours ago, just 20 more hours till it’s rebuilt the redundancy haha. oh well, at least I know what happens;)

45. 45 On February 23rd, 2010, DK said:

    Steve– Brilliant! I was finally ready to toss this and buy something else, but just decided to check back here one last time. Backing up my array ASAP to test this. Fingers crossed!

46. 46 On February 24th, 2010, DK said:

    Confirmed: Disabled checkpointing on one of two RAID groups and it came up cleanly on reboot, while the one with checkpointing still enabled had to rebuild. Note that in my case I did lose the data when recreating the RAID, so folks should certainly back up. Thanks again Steve!

47. 47 On March 4th, 2010, Paul said:

    It is pretty clear that this is an issue with the driver. The pdf that Silicon Image has provided is not quite honest and I believe that the fix is really just a bandaid.

    When I first set up my TR4M I used JBOD. Everything worked well. Very performant. No problems at all. Once configuring for RAID5 (4 x 1.5TB drives) performance plumets, problems begin.

    So, I copied 1.5 TB of data to the new array. That took almost 24 hours (which is hideously slow). The source drives were all SATA drives too, not USB. Perfmon showed the bottleneck was the array.

    Once completed I noticed that all 4 disk activity lights are on constantly. In JBOD mode they would all be on but they would all be green unless I was accessing a drive in which case it would turn orange. Now they are all solid orange all of the time.

    In an attempt to see what was accessing the array I pulled up perfmon, and looked at the disk idle time. It was 100% constantly (you have to look at idle time because % disk time can be wrong on an array). So as far as Windows 2008 R2 is concerned there is no access to the array. So either one of two things is happening here, either A) there isn’t really any activity on the array but something in the controller, backplane or driver is making it look that way or B) there is activity but it is coming from downstream of Windows (read: the controller, driver or backplane). Either case could make the driver think that there is activity on the drives and hence there would be data in the write cache. So a dirty shutdown will force a rebuild for sure. Now why a clean shutdown would also force a rebuild, that is just a bug. I know in the case of Windows we flush the write cache pretty regularly. On shutdown there is an explicit flush of the write cache. In short, there should never be data in the write cache on a clean shutdown. It there is then the driver isnt doing it right.

    So the problem is not that the OSes are not flushing the write caches as is implied in the pdf. If that were the case the there would constantly be corruption on all client PCs, Macs, Linux, and smaller servers that aren’t using a battery backed cache and it wouldnt be limited to one particular companies controller cards. The problem (at least in my case) appears to be that the array is constantly active so no amount of cache flushing is ever going to do anything. Any loss of power to the array causes the problem. In real life on a properly working system the likihood of this occuring is almost non-existent.

    You could completely disable the write cache as SI suggests. But this is a bandaid to a bad driver.

    My guess is that if you were to create an array, put no data on the array, restart, it will go through a rebuild. It might be really quick because there is no data other than the file system itself but it will go through the rebuild.

48. 48 On March 12th, 2010, Steve said:

    I was pleased I found the workaround for myself but I think I’m even more pleased about how many others this has worked for

49. 49 On March 12th, 2010, Steve B said:

    So if you still want checkpointing and a large array, which GREATLY speeds up rebuild times; a somewhat kludge work-around is to create multiple arrays on the same drives, keeping them all under 2TB and then running a JBOD dynamic disk configuration through windows (don’t use a stripe) on top of the arrays to re-create a super-large array. It works great for me since my computer is used for bunch of things and has un-clean shutdowns from time to time. Rebuilds take as little as 5 minutes if there was a shutdown problem (which has only been a couple times). FYI this is on a Windows 7 32-bit machine on a Sil-3124 card. This setup has been rock-solid for a few months now.

    Also note that Silicon Image has released new drivers for the 3114 and 3132 for windows 7, but curiously not yet for the 3124 (have not checked other cards). If anyone has those cards to test, it might be a fix for that card. I assume that they are probably going to fix the 3124 as well at some point, but their track record is not good.

    Finally, if you want to test a scenario without waiting for the entire drive to be initialized, you can make an array, do a fast format, then go into the Raid tools task manager (under the “windows” menu item in the RaidTools program) and “suspend” the initialization, then reboot. Then on reboot look to see if it performs a “restoring redundancy” before it continues the initialization (it will automatically). If it performs the dreaded RR then it will always do it on reboot, if it does not, then you are good. (A huge time saver when you are testing).

    Hope this also helps.

    Steve B

50. 50 On March 12th, 2010, Steve B said:

    Sorry, the last post was supposed to start with:

    FYI -

    I have done some further experimentation with this and found that the checkpointing bug occurs ONLY on Large arrays (>= 2TB). Smaller ones seem to be OK with checkpointing. That is probably why some people had the problem and some did not. It also might be OK when you create the RAID from the Bios GUI (since I don’t think it creates a raid with checkpointing by default), but I think that there is an issue that if it is raid re-creation and not complete creation, then the checkpointing can remain, hence why there are people with OK arrays sometimes.

51. 51 On March 13th, 2010, Nate said:

    Glad to see the workaround is working for everyone and thanks to Alex for keeping his blog up and this thread active.

    Looking to the future i dont think Silicon Image array cards are the way to go. In fact, from what i can see, they havent updated their chipset or drivers in years. Aside from the Windows 7 driver which saw an update late in 2009. I’m on Win Srv 2008 and the Silicon Image driver is over 2 years old.

    Has anyone migrated to another product or has looked into it? The HighPoint RocketRaid cards get pretty good reviews so i’m considering trying them out.

52. 52 On March 18th, 2010, Sam said:

    To get rid off this problem.

    DO NOT use “Return dirty data” option, then you do not have problem of rebuilt when ever your turn off the system.

    FOr years, I wish there is a Port multiplier hardware RAID instead of software raid solution that Silicon Image offered… months of talking to vendors, finally a company call DATOptic Inc offers it.
    Bough one and never look back at this Silion Image software raid solution

53. 53 On March 18th, 2010, Sam said:

    Opps forgot!
    In case you want to know what enclosure that I bough

    It calls eBOX-R5 - hardware raid5 enclosure

54. 54 On July 4th, 2010, Jonathan said:

    Hey Guys, THANK YOU all SO much for such clearly explained valuable information!

    I may be totally off base here, but I found something that noone anywhere has mentioned which I believe could be an integral, if not THE central issue with this whole problem!
    It is a line in the .inf file with the new driver (1.5.19) of the si3132r5 device.
    It says (line 93&94)- this is the first version to have this:
    [SI_3132_XP.NTamd64.HW]
    HKR, ScsiPort, NeedsSystemShutdownNotification, 0×00010001, 1
    Now, if I’m not mistaken this should add a line somewhere in the registry. 0×0001001 indicates a DWORD value…
    BUT no such entry exists! I can’t quite figure out where the entry should be to create it myself- I think the line may not be written properly or completely. I personally believe that if this “NeedsSystemShutdownNotification” entry were properly placed in Windows’ registry that this problem would be resolved WITH Write Caching AND Checkpointing both enabled.

    Any thoughts?

    My research into .inf files has returned too many beneficial results (not as pathetic as sil 3132r5 searches tho- LOL)

55. 55 On July 4th, 2010, Jonathan said:

    PS/FYI- I’m using Windows 7 Ultimate x64 & trying to configure a RAID 1 array of two 1.5TB disks with a PCI-E Sil3132r5 card- w/ROM v7.7.03 (no port multiplier)

56. 56 On July 13th, 2010, Lionwes said:

    Thank you All for this thread… As Steve found out, disabling the “Check Pointing” during initial configuration solves the Restore Redundancy mad-circle. This can not be done once the RAID is created however. I did backup my data and recreated the array making sure I disabled the “Check Pointing” dubious feature and rebooted with no more issues. It also gives best I/O (is says), but will take much longer to rebuild if power failure. Boy, this was such an experience finding the solution. Thank you all for your contribution…

    BTW, the Silicon Image software RAID5 works quite well in-spite being poor man’s RAID (I am a poor man anyway…) I get about 60 to 100 MB/s read with 4 drives (depending on chunk size, 8KB ~60MB/s - 128KB ~100MB/s …), and about half that much for write. BUT, the write speed depends on CPU speed and amount of RAM and it is not always that good. Because the CPU does the XOR, write speed is very limited by the PCI bus IO speed of 133MB/s. Also, with 3 hard drives you have to write ~1.5 times the data (two chunks data and one parity). Of course do not benchmark it too soon, it takes 30+ hours to build RAID5 with four 1TB drives.

57. 57 On August 5th, 2010, Andrea said:

    Hello,

    my compliments to Alex for the site and to everyone for suggestions/contributions.

    I have a Edgestore DAS801t wich bundles a card with Silicon Image Si 3132 controller/port multiplier (8 disks with two SATA channel).

    I filled the unit with eight Seagate Barracuda 1.5 TB and created one RAID 5 with five disks and RAID 0 with the remaining 3.

    I copied all my files on the RAID 5 and the system worked fine for some months even if I wasn’t very happy with the rebuilding at each boot.

    Now after a 220 V AC line failure, the RAID 5 presented an orphan drive and the others are recognized as part of RAID 5 but are all offline (pink-red colour in the block diagram).

    No way to bring them back online or rebuild the group (the relevant commands in the SATARAID utility are grayed).

    Checked all the connections and drive insertions in the bays, everything seems to be ok.

    After googleing it seems that many people experienced the same, but neither found a fix along with the description of the problem, nor had a feedback on it.

    Has someone some fix or suggestion ? Edgestore support ? Silicon Image support ?

    Please help !

    Thanks and best regards,

    Andrea (Lake Como - Italy)

58. 58 On August 12th, 2010, John C said:

    #38 KBeee’s comment “On a side note, I found that if you need to create an array, or if the array needs to rebuild parity, then running a media player in the background halves the time it takes. I was using Media Player Classic Home Cinema, and it got my rebuild time down from 52 hours to 24 hours.”

    I thought this was something silly, but out of desperation/frustration I tried it. By simply starting Windows Media Player I reduced my rebuild time from 65 hours to 12 hours. No idea why. Thanks KBeee

59. 59 On September 6th, 2010, Dave said:

    Microsoft published a hot fix (Article ID: 902853) for this problem on October 11, 2007 titled: “An unnecessary restore operation may be started on the RAID group when you put a Windows Server 2003-based or Windows XP-based computer in hibernation.”

    http://support.microsoft.com/?kbid=902853

    This correction is specifically for RAID Controllers using any of the Silicon Image RAID drivers. This hot fix is also included in the Microsoft Windows XP Service Pack 3 (SP3). You should also be sure that your controller is using the most up-to-date driver from Silicon Image.

    (Note: minor correction included in this post; please delete previous post and this line)

60. 60 On December 31st, 2010, Victor Kruger said:

    I applaud all of you for working on this issue and finding many solutions. I too suffer from this but I have a new twist that involves win7 32-bit. Everytime i need to reboot, right before the login screen, the windows loading screen will freeze and my array will just churn and churn for hours and even days.

    What is even more weird is that if the array is empty, then win7 will boot immediately. Once you start putting data on the array the loading screen will start freezing and the delays will start.

    None of the proposed solutions on this thread seem to fixes my issue, not even just putting the drives as pass-thru and using windows handle the raid fixes it.

    Luckily I still have a copy of Winxp and I’m going to put that back on….sometimes newer isn’t better…

61. 61 On January 4th, 2012, TTP said:

    OK massive issues for me… First off is there ANY way to delete the RAID array with-out it doing the 73 hours of restoring redundancy? After HOURS of experimenting I finally found a way….

    Please note ensure you don’t want any of the data on the drive! In other words back it up!

    Disable your on-board SATA if it’s BIOS prevents you from seeing the card BIOS (which mine does, not usually an issue as I can use the SATARAID5 tool).
    Create a RAID0 (not 5!) array, reboot, turn the on-board SATA back on.
    Reboot, then go into windows, ensure you delete the old array in the SATARAID5 tool, convert the BIOS made one (right click on it).
    Use the drive (Quick format, etc) to ensure the old one is gone for good, then delete the RAID0 and reboot again and…. it’s gone! FINALLY! YAY!

    This was actually the only way I could even remake the drive setup correctly (turn off checkpoint). This may have been due it originally being made on another system but unconfirmed…

    Also note this occured in thanks to windows “repairing” the drive after rebooting after spending 68 hours of array creation… Windows 7 decided it should repair the drive for me, isn’t it great?

    Now to wait yet another 48 hours of array creation… I also trialed the rebooting to ensure it doesn’t do the RR, thanks a lot to all who added comments and assistance above!

62. 62 On January 13th, 2012, Darron said:

    Hi Guys,

    I stumbled on this site after having this issue for the fist time. I have been trying to copy about 5Tb of data back to the new RAID5 volume from various smaller drives on my system. After a break in copying (all data copied from one of the disks) I let the system reboot as Windows Update was bugging me.

    Following this reboot, the RAID array wanted to rebuild again - not what I needed after several days of rebuilding and copying of data! The RAID array is slow enough without trying to copy data during a rebuild!

    I decided to start again disable check-pointing as per the fix above and hopefully this will resolve the issue.

    In direct response to TTP above, I found that if I remove all drives (except 1) I can delete the broken RAID group without needing to wait for the rebuild to finish. I then added one drive at a time and deleted each time. When all drives were re-added and raid group deleted I could then re-create the RAID5 group! That saved me a few days!

63. 63 On January 13th, 2012, Darron said:

    Odd?

    I do not have the Check Pointing option?

    I am building a new RAID array and the check point option is nowhere to be seen? It was there before, so I can only assume the latest drivers or software (which I am using) has removed this?

    Does this mean it is disabled by default?

    I do not really want to wait for a few days to see if this works…

64. 64 On February 2nd, 2013, max said:

    Cheack
    Configuration > Advanced Options >Advanced RAID Features

    Enables the selection of an Improper Shutdown Policy (including Check-Pointing and Dirty Parity handling) in the Create RAID Group dialog box when the selected RAID Group type is a fault-tolerant configuration (Mirrored, Mirrored/Striped and Parity RAID). This feature is not supported for Legacy RAID groups.

Leave a Reply