RAID 1 Intel Help

S

Syndacate

Weaksauce
Joined
Mar 5, 2009
Messages
93
Hey,

I'm testing (trying to set up) a RAID1 mirror using an EVGA 141-BL-E757-TR mobo with an Intel RAID controller.

My hard drive setup is as follows:
3TB total
1 TB = OS drive
1 TB + 1 TB = data array (RAID1)

I pulled the data cable on one of the drives and when I booted up it told me one drive was missing, which is good, ok, that's what it's supposed to do. So I believe it's working as far as recovering a lost drive (remirroring) is concerned, but what about data inconsistencies?

I pulled one of the RAID drives, it recognizes that the RAID is damaged and wants me to put another drive in. It still let me boot so ok, I boot, I dumped 3 random DLL's on the one drive that was left. I then opened the Intel RAID manager - it immediately detected that there was a problem and told me it was rebuilding the redundancy (started doing so automatically).

3 hours later now, it rebuilt the redundancy, but those 3 files aren't there. How exactly does the manager manage mirroring inconsistencies, as now it seems they're lost - which is fine for this - as it was a test, but I don't want it to arbitraily decide what stuff to boot out if somehow there's a difference in data from one drive to the next.

This is my first RAID setup of any kind (as you can probably tell), so I'm trying to figure this out, but it's obviously not going too well.

Anybody have any input? Why did it ignore those three DLL's? Does one's data always take precedence over the other's? As far as I can tell from this simple test - it just flat out erased it, which kinda defeats the point in the first place.

Anybody have anything? I'm lost :(.
 
The way it's supposed to work is that in the RAID metadata somewhere the controller stores whether the disk is in a safely stopped state, with a version number that increments with each array event (shutdown, disk failure, etc.) or something similar. When your system is running, all disks are in an unsafe state, so if one fails and is later brought back in it should both be in an unsafe state and with an old version number, so the controller knows that the other disk is the canonical copy. This is of course over simplifying how it actually works, but it should model the real life behaviour fairly well.

I have no idea why your board misbehaved, however. Even though you used the same disk, presumably without wiping it (normally you'd replace with a new blank disk), the controller should be smart enough to know that it's stale, though it might be possible to trick it if you really tried. I don't use the Intel RAID so I can't really comment further, however I'd avoid motherboard fakeraid at all costs, since you're not even trying to boot from it, just use software RAID1.
 
Lazn_Work said:
It did what it was supposed to do.. RAID is not backup. RAID is to keep running when one drive fails until you can replace that drive. It does not protect against data deletion viruses etc etc

http://puzzling.org/logs/thoughts/2009/January/3/backup-policies
Click to expand...

Did you actually read my damn post?

How did I know I was going to get some jack nuts in here sending me a link that RAID is not backup - I am well aware that RAID is not backup, BUT, if you have a RAID array as a data drive, and you backup to said RAID array, then IT IS A FORM OF BACKUP. I am WELL AWARE that RAID doesn't protect against viruses or accidental deletion, I don't need you to tell me this.

Please, if you have nothing useful to contribute (or in your case aren't even going to bother to read the damn thread), don't say anything. My question had absolutely nothing to do with viruses or data deletion.

I was simply testing what would happen if there was a data inconsistency between the mirror - I did so by deleting a file that was on one drive, independently. This creates an inconsistency across the bridge. The result of nothing being there after the RAID repaired itself was simply perplexing to me.

God, I knew I was going to get some jack nuts out here telling me it's not backup with some useless information link telling me shit I already know. I am well aware what RAID does, but be that as it may, it CAN BE USED TO PROTECT A BACKUP that is on a LOGICAL VOLUME.

I'll give you an example, since I'm guessing somebody who didn't bother to read the thread, isn't following me at this point.
If I make a word document, and save it on my regular OS drive, then fine, ok. If I back it up (via std copy, regular drag and drop) onto the RAID array (a RAID1 mirror), it is "backed up" onto the RAID array. That disk (or rather, either disk), is PROTECTED by the array. So no, "TECHNICALLY" it's not backup, but due to what its actual function is, it damn sure can be used as so.

Please, go away.

keenan said:
The way it's supposed to work is that in the RAID metadata somewhere the controller stores whether the disk is in a safely stopped state, with a version number that increments with each array event (shutdown, disk failure, etc.) or something similar. When your system is running, all disks are in an unsafe state, so if one fails and is later brought back in it should both be in an unsafe state and with an old version number, so the controller knows that the other disk is the canonical copy. This is of course over simplifying how it actually works, but it should model the real life behaviour fairly well.

I have no idea why your board misbehaved, however. Even though you used the same disk, presumably without wiping it (normally you'd replace with a new blank disk), the controller should be smart enough to know that it's stale, though it might be possible to trick it if you really tried. I don't use the Intel RAID so I can't really comment further, however I'd avoid motherboard fakeraid at all costs, since you're not even trying to boot from it, just use software RAID1.
Click to expand...

So you're saying that if I had put the file on ONE of the drives after (as in it wasn't on when both drives were plugged in) the RAID separated, then when it reassembles the RAID, it would show that the drive that had the last revision for that file (ie. the one I just put it on) is supposed to exist, and then when it would repair it and add that to the second drive without it? (wow, that's ass backwards).

Lemme rephrase b/c that's just confusing:
If I disconnect one of the RAID drives, then put a file onto the remaining drive, after I reboot, when it rebuilds the RAID, that file should be on the RAID volume that was produced via the redundancy rebuild, right? As that revision of it was made AFTER there was nothing on it, and the metadata should take care of the whole revision control, right?

Thanks for your very useful reply, I didn't know the metadata kept any kind of revisions.

I was just wondering with what would happen if something weird happened (like say the power cable fell out) to one drive while it was writing to the array and there was a data inconsistency. Judging by your answer, I'd say you know what I mean.

Thanks, I'll test it the other way now, see if the file remains after the redundancy rebuild.
 
wow way to overreact. lol

It sounds to me like you expected the files you deleted to come back. That is not what RAID is for. It is what backup is for, and this is why I answered in the way I did.

If you want to save a copy of some data by breaking a mirror (RAID 1) it can be done. You would have to boot off the saved drive in a degraded array (pulling the drive with the deleted data) then rebuild from it, rather than rebuild from the drive that you deleted the data from.

However this is not really the intention of RAID.
 
The RAID itself is totally unaware of 'files' on the filesystem, it's just a block device. A 'rebuild' just consists of copying every byte on one disk to the other disk. What's supposed to happen is that if a drive fails, it gets knocked off the array and the metadata is still set as 'unclean' with revision 1, say. As you continue to work on the remaining disk, the revision is incremented to, say 3. When you put the failed disk back into the array, it will see that the good disk has a newer revision and use it as the 'master' disk, copying everything from that good disk onto the replacement/old one.

So in your situation if you removed a disk from the array, then added files to the array and added the disk back, the files should remain after a rebuild since the removed disk would be marked as failed, and when you reconnect it, it's basically the same as if you'd added a blank new disk.
 
keenan said:
The RAID itself is totally unaware of 'files' on the filesystem, it's just a block device. A 'rebuild' just consists of copying every byte on one disk to the other disk. What's supposed to happen is that if a drive fails, it gets knocked off the array and the metadata is still set as 'unclean' with revision 1, say. As you continue to work on the remaining disk, the revision is incremented to, say 3. When you put the failed disk back into the array, it will see that the good disk has a newer revision and use it as the 'master' disk, copying everything from that good disk onto the replacement/old one.

So in your situation if you removed a disk from the array, then added files to the array and added the disk back, the files should remain after a rebuild since the removed disk would be marked as failed, and when you reconnect it, it's basically the same as if you'd added a blank new disk.
Click to expand...

I would add that I would expect that the entire contents of the "good" drive will be copied to the "new" drive. That is: if you have a full 1TB drive, in this instance it will probably recopy the entire 1TB to the re-inserted drive and not just the new (or deleted as previously asked) data.
 
Lazn_Work said:
wow way to overreact. lol

It sounds to me like you expected the files you deleted to come back. That is not what RAID is for. It is what backup is for, and this is why I answered in the way I did.

If you want to save a copy of some data by breaking a mirror (RAID 1) it can be done. You would have to boot off the saved drive in a degraded array (pulling the drive with the deleted data) then rebuild from it, rather than rebuild from the drive that you deleted the data from.

However this is not really the intention of RAID.
Click to expand...

I'm sorry I reacted the way I did, but I just KNEW somebody was going to come on and give me that line of crap. I saw that coming before I even created the thread.

I know what a backup is for, I know what a RAID is for, but if you look at what RAID is by definition, and I put a backup images or files ON a RAID array, then RAID can protect a backup, which is what I'm doing.

So it is what RAID is for in my case, I'm not looking to have it save my data, but I want data that I put on it, which is backups of what's on my OS drive. It's just protecting my backup drive. So in my opinion, for my situation, it is for backup purposes, as in, if I store all my documents/pictures/music on it, they're protected against a one drive failure.

Unless I'm missing some critical part of RAID1, for MY PURPOSES, RAID is a backup. It's a backup for my backup, in reality. It's just an insurance policy if my "data" drive craps out. So unless I'm drastically missing something on the functions of RAID1, and what mirroring actually is, it can serve my purpose absolutely fine.

keenan said:
The RAID itself is totally unaware of 'files' on the filesystem, it's just a block device. A 'rebuild' just consists of copying every byte on one disk to the other disk. What's supposed to happen is that if a drive fails, it gets knocked off the array and the metadata is still set as 'unclean' with revision 1, say. As you continue to work on the remaining disk, the revision is incremented to, say 3. When you put the failed disk back into the array, it will see that the good disk has a newer revision and use it as the 'master' disk, copying everything from that good disk onto the replacement/old one.

So in your situation if you removed a disk from the array, then added files to the array and added the disk back, the files should remain after a rebuild since the removed disk would be marked as failed, and when you reconnect it, it's basically the same as if you'd added a blank new disk.
Click to expand...

Yeah, I figured it was just a byte for byte transfer on the rebuild. I see what you're saying now. I was simply unaware of the method used to determine which drive was copied onto what. It makes sense now, as I had removed the files from the one drive AFTER I separated the RAID.

After reading your last post I did the experiment again, but I reversed it. I:
- Shut down the computer
- Pulled one of the RAID hard drives
- Booted windows (it recognized the array as degraded), put a bunch of random DLL files on it (3 to be exact)
- Shut down the computer again
- Plugged in the other drive, started the OS
- The Intel Matrix RAID drivers hit it up instantly.

At the end, the three files were remaining, as the metadata saw that they were added last, and it was closed to a safe state.

Thank you very much for your response.

Lazn_Work said:
I would add that I would expect that the entire contents of the "good" drive will be copied to the "new" drive. That is: if you have a full 1TB drive, in this instance it will probably recopy the entire 1TB to the re-inserted drive and not just the new (or deleted as previously asked) data.
Click to expand...

Yes, I believe you are correct. Unless it took 3 hours to copy 3 small DLL files :-P. Yeah, I'm guessing it's a complete byte for byte copy, as keenan said earlier.

Thank you both, very much for your posts, I got the issue situated now.
 
You must log in or register to reply here.
Back
Top