From owner-freebsd-hardware@FreeBSD.ORG Tue Oct 12 00:50:49 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 B3E2C16A4CE for ; Tue, 12 Oct 2004 00:50:49 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631AB43D3F for ; Tue, 12 Oct 2004 00:50:49 +0000 (GMT) (envelope-from Roisin.Murphy@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so326976rnk for ; Mon, 11 Oct 2004 17:50:49 -0700 (PDT) Received: by 10.38.126.23 with SMTP id y23mr1950281rnc; Mon, 11 Oct 2004 17:50:48 -0700 (PDT) Received: by 10.38.171.45 with HTTP; Mon, 11 Oct 2004 17:50:48 -0700 (PDT) Message-ID: Date: Mon, 11 Oct 2004 17:50:48 -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: Tue, 12 Oct 2004 00:50:49 -0000 thanks, i hope i'm not running in circles now :) > most RAID controllers run in write back caching mode. 3. Do you think the raid controller could also keep the info on how the data is spread across the disk platters? From what i understand, the write back cache on disks, is there to avoid the disk heads from having to jump from sector 1 to sector 500 to sector 2, but instead allow it to go from 1 to 2 to 500. But if the controller would know how the data is spread, it could use its cache to send the bits in a preferable order. So the controller itself is like another layer, so there really isn't any need for cache on the disks. And thats what i was asking, as you yourself mentioned that you think scsi controllers usually turn the cache off on scsi disks anyway. So therefor i asked, what the difference was between scsi and (s)ata disks, when both have disks write cache off. I do understand the tagged queueing concept now, but if the cache is off on the scsi disk, and the controller's cache is used, it shouldn't matter. > A "dead" array implies that you have two failed disks. 2. well, i have to ask that guy i know, who does a lot of incident response type of work, what exactly happened to all those 'messed up' (s)ata raid arrays. I didn't know, you could recover from a power outage situation, where you end up with inconsistent parity. 3. As i said, i wont be running any critical transactional db, that would end up in an inconsistent state if the power goes out, and the disks reported all the writes (but instead they were pending in the disk cache). So the db finished the transaction, but after the crash&reboot, some tables will be modified and some won't. ALL I'm concerned about is, that my whole raid setup could die because of an inconsistent parity. I don't really mind loosing/corrupting few individual files. > If you want the cheapest solution, and something somewhat reliable, you > could go with software RAID on SATA disks, and put the machine on a UPS. > With a UPS, you could run with write caching turned on on the drives, and > without a battery backed RAID controller cache and not worry about it too > much. As long as your UPS has enough power to shut down the machine, > you'll be fine. 4. In my experience, my PSU or any flaky hardare in my box breaks more often then there are power outages in my area :) > The only problem with pure software RAID is that you generally can't boot > off of anything other than a RAID-1. (Even then you may have issues.) So > your boot disk won't have any protection. 5. the boot disks usually don't matter, as long as you backup your configuration, when its changed... 6. anyway, thanks for taking time to explain stuff in detail :)