This allows any RAID5 based system with a write coalescing capability to also be called RAID3. Whilst this may reflect an occasional ability for the system to write in RAID3 mode, the type of striping is still block oriented, thus allowing a host write to the disk subsystem to be less than the RAID stripe and result in the normal RAID5 write penalty for many operations. Additionally, the independent operation of the internal disks with block oriented striping means that reads will not allow real-time verification of the RAID ECC, losing a key benefit of true RAID3. ECC verification in a RAID with independent disks is likely to result in a significant performance overhead, so the result is they don't do it or it is an off-line or overnight task. Since the standard SCSI protocol does not allow for generic internal RAID conditions to be signalled, each manufacturer must sponsor his own method of management and error reporting.
Some vendors generate their own device drivers, others manage the array through a terminal line.
The first option seems to be commonplace in situations where the host system manufacturer and the RAID manufacturer are the same. The second option is popular with 3rd party RAID vendors. Baydel employs the second method, allowing the RAID to be seen as a standard disk device on every platform with SCSI support and with management carried out through a Graphical User Interface, through the host and through the RAID terminal port. RAID systems with device drivers tend to be less flexible, i.e. may be limited to certain SCSI interfaces and systems. RAID systems with RS232 management are free from host platform driver requirements.