Date: Fri, 06 Feb 2004 10:59:06 +0000 From: Guy Dawson <guy@crossflight.co.uk> To: listac@nebelschwaden.de Cc: freebsd-hardware@freebsd.org Subject: Re: SATA RAID 5 controller for FreeBSD Message-ID: <4023737A.7020807@crossflight.co.uk> In-Reply-To: <4022A2CE.5040504@nebelschwaden.de> References: <002401c3e661$32b27c00$0c00a8c0@artem> <401FE932.9060401@web.de> <4022A2CE.5040504@nebelschwaden.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. **********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4023737A.7020807>