SATA RAID 5 controller for FreeBSD

Guy Dawson guy at crossflight.co.uk
Fri Feb 6 02:59:12 PST 2004


Ede Wolf wrote:

>> It does not have cache as the hard disks and the OS have. There is no 
>> need.
> 
> 
> I am by no means a RAID expert and this might be slightly off topic, but 
> I've realized, that SCSI-Disks used in a RAID always have their 
> write-cache disabled.

I don't know about the always bit but this is good practice.

> Not sure why, but I guess partly for control meaning that if the
 > controller flushes its cache, it can be sure that data is on the disk.

More importantly is that if not all of the data is on the disk it's
possible to work out at what point data was no longer being stored on
the disk.

Filesystems deisgners and coders take great to define and control the
order in which filesystem data is written to disk. This makes error
recovery following a power failure much easier.

Disk write caches tend to be used to optimise the speed at which data
is written to disk. So if the filesystem wants to write to sectors

	1	2345	2

in that order (for the above reasons) chances are that a disk write
cache will re-order the writes as

	1	2	2345

Even worse is the fact that not even this assumption can be made. We
simply don't know which order the writes were done in. This makes
crash revocer really hard.

> With write cache enabled, the controler has no real knowledge of the 
> state of the drives and may be "confused"  by extremely different speeds 
> (writing data to an empty cache on drive 1 while drive 2 is busy writing 
> its own cache to disk).

This should not happen. RAID controllers and SCSI disks are quite smart
and the disk can tell the controller (RAID or other) that its buffer is
full and that no more data can be sent yet.

> So basically the cache on the controller is an replacement for those on 
> the drives.

Caches in front of slow resources do means that the cache can be
written to very quickly which frees up other resources such as the
PCI bus. With out any cache a write from main memory to disk would
hog the PCI buss for longer. Chances are the transfer would be split
due to the length of time it took. More PCI bus bandwidth would be
uses sorting out which controller would have the bus next.

> This may be complete bollocks, only what I've been told, but maybe 
> someone would be so kind to clearify, since I am not aware one can 
> disable write cache on ATA drives.

There are some DOS based programs for some ATA disks that can be used
to do this. I think Quantum/Maxtor have one.

> Which even may not be relevant.

Write caches on ATA disk present exactly the same problem as write
caches on SCSI disks.

It's one of the very good technical reasons for prefering SCSI over
ATA - being able to turn the write cache off. Trying to explain to
management what this is all about and why a £400 147GB SCSI disk may
be preferable to a £150 250GB SATA disk is a different problem!

Guy
-- --------------------------------------------------------------------
Guy Dawson                    I.T. Manager              Crossflight Ltd
guy at crossflight.co.uk         07973  797819                01753 776104



**********************************************************************
This email contains the views and opinions of a Crossflight Limited
employee and at this stage are in no way a direct representation of
Crossflight Limited.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. To ensure the integrity and appropriate use of
its email system, Crossflight Limited reserves the right to examine
any email held on its email system or sent to or from it.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
We strongly recommend that you check this email with your own virus
software as Crossflight Limited will not be held responsible for any
damage caused by viruses as a result of opening this email.
**********************************************************************



More information about the freebsd-hardware mailing list