From owner-freebsd-current@FreeBSD.ORG Wed Nov 7 13:09:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56EE216A419 for ; Wed, 7 Nov 2007 13:09:02 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 216AF13C4D3 for ; Wed, 7 Nov 2007 13:09:01 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:63255 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IpkeB-000FWJ-4s for freebsd-current@freebsd.org; Wed, 07 Nov 2007 13:08:43 +0000 Message-ID: <4731B8DA.8010201@conducive.net> Date: Wed, 07 Nov 2007 08:08:42 -0500 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <487375.1457.qm@web30309.mail.mud.yahoo.com> <9bbcef730711070450x308129b4rb18577c317eee197@mail.gmail.com> In-Reply-To: <9bbcef730711070450x308129b4rb18577c317eee197@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: geom_raid5 inclusion in HEAD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2007 13:09:02 -0000 Ivan Voras wrote: > On 07/11/2007, Arne Wörner wrote: > >> graid5 puts write requests for about kern.geom.raid5.wdt seconds (but not less >> than 1-2 seconds) into the write cache (if there is enough space left in >> graid5's write cache)... I would guess that this behaviour is pretty >> incompatible with soft-updates with power outage... > > Can this cache be disabled? Probably - but recent info shows it to be the prime mover in providing decent performance (when things are NOT broken). > >> Then there still is the write cache of the hard discs (I dont know how long it >> waits, but that time would come in addition to graid5's delay)... >> >> Maybe gjournal could help, because graid5 honors the BIO_FLUSH, but that is >> untested... > > Yes, AFAIK this would work. > A RAID5 is one of the harder ones to do both fast and well in software-only. The better hardware ($$$) controllers have fast hardware XOR engines as well as CPU-as-state-machines and battery-backed cache, and THEY have to work hard. Further, a hardware controller sits in the right place to do the job well, the 'GP' CPU(s) - no matter they have spare cycles to burn - do not. I don't think even GEOM magic can get around that w/o user willingness to take on some unavoidable compromises. Given decent hardware & any UPS that costs less than the hardware controller, these are 'choices' - not really show-stoppers. Bill