From owner-freebsd-stable@FreeBSD.ORG Fri Nov 4 06:47:51 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD06816A41F for ; Fri, 4 Nov 2005 06:47:51 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77CF843D46 for ; Fri, 4 Nov 2005 06:47:51 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id jA46lojc091757; Fri, 4 Nov 2005 00:47:50 -0600 (CST) (envelope-from dan) Date: Fri, 4 Nov 2005 00:47:50 -0600 From: Dan Nelson To: Brad Knowles Message-ID: <20051104064750.GG67512@dan.emsphone.com> References: <0E972CEE334BFE4291CD07E056C76ED807738005@bragi.housing.ufl.edu> <20051103133248.Y60367@zoraida.natserv.net> <436A5B7D.6090408@mac.com> <20051103143332.B60864@zoraida.natserv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.11 Cc: francisco@natserv.net, stable@freebsd.org Subject: Re: Disk 100% busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 06:47:52 -0000 In the last episode (Nov 04), Brad Knowles said: > At 2:35 PM -0500 2005-11-03, Francisco Reyes wrote: > >> If you're using maildir, that is one of the situations which works > >> pretty well with RAID-5, although RAID-10 is also (always? :-) a > >> good choice. > > > > How about for database? In particular postgresql. How bad would > > RAID 5 be for it? > > RAID-5 is usually about the worst case for most database > applications, since you have to read and write entire blocks across > all disks just to change a single bit. You have to wait for all > disks to read or write their respective data, before you can return. > Some RAID arrays will have intelligent controllers that allow you to > cache writes and return before the data is actually written, but then > intelligent controllers can be used with all RAID types. Even though parity is calculated across all disks, you don't need to read all the blocks to recompute parity during a write; you just need to know the contents of the block you are about to update and the contents of the parity block you're about to update. This cuts write speeds to 25% in a simple implementation, but with a large enough write cache in your controller, it can delay the I/Os until idle times (or avoid the penalty completely if an entire stripe of data gets modified). -- Dan Nelson dnelson@allantgroup.com