RE: General RAID5 question - dangers?

From: psyklops@my-deja.com > >Wouldn't parity verification on RAID-5 seem redundant since >the "reverse" of the parity should be the actual user data written. If >the parity is incorrect, then the data would also be incorrect and if >so, would be of greater concern than the parity data itself? But the parity gets "calculated", and is therefore more susceptible to faults. And the other issue is not RAID parity, but the low-level disk parity that can fail all by itself... :-) >RAID-1 whether hardware or software RAID needs to verify that data is >identical on both volumes (hence mirrored). If the data is not >identical on both volumes and a disk fails, data integrity is >compromised and implementing a RAID-1 solution would not be useful. > >As for the XP256, the array is cache centric. Therefore all reads and >writes hit the cache first and then serviced to the host/disk. As RAID- >5 is much slower in writes, it is generally not preferred in database >environments where a large number of writes is done. However, the >XP256 will read the entire RAID-5 stripe to cache memory regardless of >the size of the read/write. All read's and writes are then serviced >from cache memory until the array decides to de-stage the stripe to >disk. The XP256 can accomodate RAID-1 and RAID-5 within the same array >for environments that require it. For maximum tuning, certain heavily >hit volumes "hot spots" can be permanently locked in cache using a >special software package for the XP256 - all writes/reads to this area >(possibly redo logs) can be serviced directly from cache memory... So it has a bit more than 64MB cache? ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com