As I mentioned in another thread, I have two RAID-5 arrays, a primary one that serves the immediate storage needs of my family, and a backup, which syncs with the primary every night at 3 AM. Each RAID-5 consists of 3 2 TB Seagate (5900RPM) disks. Recently I purchased 2 more 2 TB disks to expand the arrays by 2 more TB (burning 8 GB ISOs takes up a lot of room). I added each new disk to the respective systems, but only initiated an expansion of the backup array first, in case anything went wrong, as this was my first attempt at online capacity expansion of an array with precious data. All went well with that expansion; it took 2 1/2 days, but otherwise everything went as planned. I proceeded to initiate the expansion of the live array and that went well for the first day and then everything slowed to a crawl at about 30% migrated. It has been migrating at the rate of just under 3% a day for the last week and I'm up to about 50% now. This is just does not seem right. Both RAID systems are identical, hardware-wise, however the active array runs under Windows 2008 R2 DataCenter and the backup array runs under Windows 7 Professional. Also, the active array is running RST 10.1.0.1008, while the backup array is running the newer 10.8.0.1003 - this is because Intel has not published an update for RST on Windows 2008 R2 Server beyond 10.1.0.1008.
So does anyone know of any migration slowness issues with 10.1.0.1008?
And, additionally, is it okay to deploy the Windows 7 64 bit RST 10.8.0.1003 on Windows 2008 R2? If so, I will update as soon as the migration completes in about, oh, 3 weeks.
I know there is an additional difference in that the active array is being, well, actively wirtten to, but we have stopped using it after the slowness occurred, to see if that would make a difference, but it did not.
Got bored with waiting (I'm at 58% migrated now) and installed 10.8.0.1003.
Computer continually reboots during load of Windows.
No System Restore on Windows 2008 R2 Server, so instead I used F8 on bootup and selected Last Known Good Configuration.
That got me into Windows.
The UI now reports 10.8.0.1003 but I suspect the driver has been rolled back.
The UI sees the array and the drives, but does not see the raid volume at all and does not report any migration taking place, although migration IS taking place (I can hear it) and the drive letter is present and working in Explorer.
Don't know where I'll go from here, but thought it would be good to let people know that upgrading RST during a migration is asking for a heap of trouble.
Well, here I am two weeks into my migration and I'm at just over 70%
I have at least another week to go, probably more.
I can understand taking a couple DAYs, because, after all, were dealing with terra-bytes here, but WEEKs...something is wrong.
Additionally, I have started noticing errors on the migrating volume when my sync to the backup RAID takes place at 3AM.
Bad signs all around.
What I'd like to do is just STOP and CANCEL the migration, apply the latest RST (since applying during migration results in the infinite reboot of death), and then try migrating all over again.
I don't think you can just stop the migration though.
An alternative is to just wipe everything and resync with the backup raid.
That leaves me more vulnerable than I'd like, so I'm trying to avoid it.
I would like to hear some comments from Intel people, if they are monitoring this board, specifically, I would like responses to the following 2 questions:
1. Is it okay to apply RST 10.8.0.1003 to a Windows 2008 R2 Server (64 bit) even though it is not listed in the officially supported operating system list?
2. Is there any way I can stop a migration (without damaging the volume) once it has started?
Well, it happened, the migration failed.
What's worse is that it did not KNOW it failed.
The status of the array was still "migrating" as if everything was okay...but it wasn't.
Random EXE files started to become corrupted.
How did I notice that?
Well, Windows would say something like "this executable is not compatible with the OS you're running it upon" or something like that when trying to run these EXEs.
I immediately did a compare of the corrupted EXE against the copy on my backup raid and found that there were differences.
There were also differences in data files like INI files.
I wondered why my daily sync backup did not copy the corruption and then realized that the file contents became corrupt but the size and timestamp on them did not change, hence the sync-ing software did not see any change and copy the corrupted files to backup - and good thing, or I would be up the creek!
I immediately deleted the volume and started all over.
I also installed 10.8.0.1003 and the system did NOT reboot while loading Windows, whew.
The new volume is now intializing, and hopefully I'll get everything copied back over without further incident.
Let this be a warning that only a fool would initiate an array operation like a migration without a backup somewhere else...but really...shame on Intel because this SHOULD have worked - and it DID work for the backup array, which went through the migration without a hitch 2 and a half weeks ago - the difference: the backup array ran on a different version of windows (win 7 pro vs server 2008 r2) with a different version of RST (10.8.0.1003 vs 10.1.0.1008) and had a different strip size (128 vs 64).
Who knows which one caused the problem, or if it was a combination, or something else.
I'm just glad I still have my data.