From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 02:21:58 2006 Return-Path: X-Original-To: freebsd-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 3C1EE16A41F for ; Fri, 6 Jan 2006 02:21:58 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF89043D46 for ; Fri, 6 Jan 2006 02:21:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id D61CB4D20E; Fri, 6 Jan 2006 02:22:03 +0000 (GMT) Received: from [192.168.0.2] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id DE1214D21A; Fri, 6 Jan 2006 02:22:02 +0000 (GMT) Message-ID: <43BDD444.80509@roq.com> Date: Fri, 06 Jan 2006 13:21:56 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Mitchell References: <20060105224150.GA991@tuatara.fishballoon.org> In-Reply-To: <20060105224150.GA991@tuatara.fishballoon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? 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, 06 Jan 2006 02:21:58 -0000 Scott Mitchell wrote: >Hi all, > >I may be getting a new Dell PE1850 soon, to replace our ancient CVS server >(still running 4-STABLE). The new machine will ideally run 6.0 and have a >PERC4e/DC RAID card - the one with battery-backed cache. This is listed as >supported by amr(4), but I'm wondering how well it actually works in the >case of a disk failure. Will the driver tell me that disk has failed (a >syslog message would be enough) or will I have to make a daily trip into >the server room to check the front panel lights? Presumably it handles >hot-swapping a replacement drive OK? > >I found some posts mentioning some management/monitoring tools for these >controllers that were allegedly available from the www.lsilogic.com >website, but I can't find anything on there for FreeBSD. Do the Linux >tools work? > > FYI there also has been a big update to the amr driver which claims to dramatically increase performance among other things, interestingly enought it was augmented by Yahoo, I can only assume they are moving to Dell, yahoo for me (and now you :). The updates are still in -current but it will be MFC'ed into stable sooner or later. http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html Log: Mega update to the LSI MegaRAID driver: 1. Implement a large set of ioctl shims so that the Linux management apps from LSI will work. This includes infrastructure to support adding, deleting and rescanning arrays at runtime. This is based on work from Doug Ambrosko, heavily augmented by LSI and Yahoo. 2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM can now operate without the cost of bounce buffers. Cards that cannot do 64-bit DMA will automatically revert to using bounce buffers. This option can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader. It should only be turned off for debugging purposes. This work was sponsored by Yahoo. 3. Streamline the command delivery and interrupt handler paths after much discussion with Dell and LSI. The logic now closely matches the intended design, making it both more robust and much faster. Certain i/o failures under heavy load should be fixed with this. 4. Optimize the locking. In the interrupt handler, the card can be checked for completed commands without any locks held, due to the handler being implicitely serialized and there being no need to look at any shared data. Only grab the lock to return the command structure to the free pool. A small optimization can still be made to collect all of the completions together and then free them together under a single lock. Items 3 and 4 significantly increase the performance of the driver. On an LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my testing with these changes. However, these changes are still fairly experimental and shouldn't be merged to 6.x until there is more testing. Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards this.