The "Synchronize data between two drives", although I mine I don't see a button I have "Menu Options", will read the primary drive and make sure the backup drives data is exactly the same.
This verification is accomplished by reading every sector on the primary drive and comparing it to the corresponding sector on the backup drive. It doesn't bother with any checksums, aside from the ones already appended by the drive to each sector. It is just a brute force sector by sector read and compare.
The advantage tot this, is that the actual hardware doesn't have to know anything about files systems. The Operating system will take care of all of that.
In almost all cases electronics are "not exact", they are rather "statistically exact". (My terminology, but I think it is correct.)
All electronics are created with a series of possible errors. some of the errors are expected and recoverable while other errors are not recoverable. (Almost universally refered to as "soft errors" and "hard errors".)
The published "hard error rate" for Western Digital Raptors is "<1 in 10 to the 15 bits read". (I wasn't able to find any other published error rates.)
A somewhat less discussed error is that of errors thare are not caught! This would be errors that do occur, but are not caught by the hardware. (This event would occur far less that the read error rate!)
That is one way for the drives to get out of sync, but there are a lot more ways as well.
A glitch in the BIOS may possibly cause a write to a sector on a drive.
Someone may boot up with the wrong drivers causing errant writes to a drive.
Maybe a sector is becoming marginal and data written there goes bad?
Some rogue program, or driver, is interferring with the writing of data to the disk. Or is even writing it's own data!
Suffice it to say, in a working system you could conceivably "NEVER" have a synchronization problem between two drives. (In my case, I have 4 servers running Mirrored Raptors that synchronize each sunday night and after about 4 months not one synchronization problem!)
As far as "Which drives data does it use?"
I think that Promise will use the first drive in your array creation as the primary drive. All considerations are made from that. In the Promise BIOS configuration it would be the top drive in the list. (Which I think is ALWAYS the lowest numbered drive for the SATA RAID channels. I DO NOT know this for sure though because I would NEVER try to create an array any other way. Maybe this coming week I will try to create an array with "Drive 2" and then "Drive 1" and see if it stays in the list that way?)
Promise doesn't do a whole lot of fancy stuff.
It writes VERY LIMITED information to the drives themselves for the RAID configuration.
The really good thing about that is the you can mirror some drives, break them out of the mirror and use them to boot other systems on SATA running in IDE mode! (Providing, of course, the drives have already been loaded! This way no-one will pop up saying, "NO, NO! You will have the RAID drives installed so when you go to SATA IDE mode it won't find the boot device!" I know, and normally I would assume others would know too, but this is here so there is NO confusion.)
It writes some other stuff to the drives as well, so that it knows the last time the drive was updated, and that may affect which drive becomes the primary drive for synchronization as well. (For instance, "Drive 1" was initially used as the Primary for synchronizations, then it failed. "Drive 2" was the only one being updated until "Drive 1" was replaced. Now "Drive 2" may become the primary for synchronozations, and it may be the one that gets written to first all of the time.)
But I use the Promise cards ALOT, and have been very happy with them.
Just set the Promise Array Management program to synchronize each sunday and send you and email! Then you will know. (Or whatever schedule suits you.)
NOTE: Use Promise Array Management 4.x.x.xx or above! (I am using 18.104.22.168) Some versions/configurations prior to that exhibit a memory leak and will crash the system after a period of time. (In my case(s) after 2-5 days.) Aside from some things I would like my version of Promise Array Management to do, I have found NO flaws in this version.
NOTE: Another thing I found recently, is that now that Promise writes some information to the hard drive about what array it is, and where in the array it belongs if you switch hard drives around prior to booting you can confuse the Promise card. (For instance, take on drive from one array and another drive from a separate array, but one that is largely similar? I had the Promise array card take about 5 minutes to boot the array. It did eventually boot CORRECTLY, but it was a pain.)
I think this is accurate.
OH! There is ONE more thing!
The current SATA Promise cards DON'T support multiple cards in a singl system! It can be done, but it's not really supported. If you do want this, make sure the cards use different drivers, if they use the same drives you can run in to problems. This is not usually a problem though since most Promise RAID controllers on the motherboard and on add-on cards use different drivers anyway.
This disturbed me since the Promise SX-6000's that I used before were designed for up to four cards per system.