From owner-freebsd-hardware@FreeBSD.ORG Mon Oct 11 01:19:13 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BEA216A4CE for ; Mon, 11 Oct 2004 01:19:13 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 178F143D31 for ; Mon, 11 Oct 2004 01:19:12 +0000 (GMT) (envelope-from Roisin.Murphy@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so407627rnl for ; Sun, 10 Oct 2004 18:19:11 -0700 (PDT) Received: by 10.38.74.32 with SMTP id w32mr1343116rna; Sun, 10 Oct 2004 18:19:11 -0700 (PDT) Received: by 10.38.171.45 with HTTP; Sun, 10 Oct 2004 18:19:11 -0700 (PDT) Message-ID: Date: Sun, 10 Oct 2004 18:19:11 -0700 From: Roisin Murphy To: freebsd-hardware@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: sata raid & write cache state X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Roisin Murphy List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 01:19:13 -0000 hi I'm thinking of setting up a raid array with sata disks so far this intel controller seems to be winning :) http://www.intel.com/design/servers/RAID/SRCS16/ the handbook says: 11.12.1.5 hw.ata.wc FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. The problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives not only write data to disk out of order, but will sometimes delay writing some blocks indefinitely when under heavy disk loads. A crash or power failure may cause serious file system corruption. FreeBSD's default was changed to be safe. Unfortunately, the result was such a huge performance loss that we changed write caching back to on by default after the release. You should check the default on your system by observing the hw.ata.wc sysctl variable. If IDE write caching is turned off, you can turn it back on by setting the kernel variable back to 1. This must be done from the boot loader at boot time. Attempting to do it after the kernel boots will have no effect. well, this is what i also heard from a friend of mine, that he has seen too many dead ide raid setups, because of that ata command set, that has no way to tell the state of the write cache content. 1. now, the question is, is this the same with the SATA command set? or is sata more like scsi in this respect? 2. i haven't read much about raid controllers yet, but i would think that with a proper hardware raid5 controller, there's no need for write cache being enabled on the actual disks, as the controller with its cache could optimize the disk writes. Is this so? does a proper hardware raid controller switch the cache off on its disks? 3. Is this the case with scsi also? if the disk could fully report write cache state, the array couldn't mess up/die like they report it with ide raid setups, right? is the disk write cache enabled on scsi raid5 setups? 4. with that intel SRCS16 controller, would hw.ata.wc sysctl work? could i turn the cache off on my sata disks like that? or do i need that manufacturer DOS floppy with utilities to turn the defaults on/off on my disks? (ideally the controller would take care of this) 5. also that intel SRCS16 controller should support 'online capacity expansion' < that means if i start with 3 disks, i can add more disk if i need more storage, without having to recreate the array from scratch? thanks