From owner-freebsd-stable@FreeBSD.ORG Fri May 11 19:56:14 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9DA816A400 for ; Fri, 11 May 2007 19:56:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4703C13C455 for ; Fri, 11 May 2007 19:56:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l4BJtqww025860; Fri, 11 May 2007 13:55:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4644CA42.3040706@samsco.org> Date: Fri, 11 May 2007 13:55:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: David Wolfskill , stable@freebsd.org References: <20070510200211.GM64542@bunrab.catwhisker.org> <4643A739.3080601@samsco.org> <20070511191511.GX64542@bunrab.catwhisker.org> In-Reply-To: <20070511191511.GX64542@bunrab.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 11 May 2007 13:55:53 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Subject: Re: 6.2-R on Dell Poweredge 2950 with Dell PERC 5/i [mfi(4)] 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, 11 May 2007 19:56:14 -0000 David Wolfskill wrote: > On Thu, May 10, 2007 at 05:14:01PM -0600, Scott Long wrote: >> ... >> Not sure that this impression is entirely accurate. The biggest problem >> with MFI machines is online RAID management. The storage driver itself >> matured very quickly and has been very reliable. > > Ah; good to know: thank you. > >>> Well, now a colleague is trying to run 6.2-R on one of these 2950s; dmesg >>> says the controller is: >>> >>> mfi0: mem 0xd80f0000-0xd80fffff,0xfc4e0000-0xfc4fffff irq >>> 78 at device 14.0 on pci2 >> ... >>> and the disks looks like: >>> >>> mfid0: on mfi0 >>> mfid0: 418176MB (856424448 sectors) RAID volume '' is optimal >>> >> Looks A OK to me. > > Even better. :-) > >>> The intended production workload involves creation and deletion of >>> a large number of files rather rapidly. >> ... >> sysctl vfs.ffs.doasyncfree=0 might help. Running the syncer more >> frequently might also help, but I don't recall the sysctl node for >> that. > > OK; I've relayed your suggestion to my colleague, but haven't heard back > from her yet. > >> ... >> Very strange. No chance that it was due to files that were deleted but >> still referenced by open apps? > > I don't think so. She's deployed 13 other boxen over the last few years > with -- naturally! -- different hardware specs, but all running > essentailly the same application. > > The big question for her is whether or not the Dell 2950, as specified, > will do the job. > >> ... >> This sounds purely like a filesystem issue, not an MFI driver issue. > > Hmmm... I'll admit to knowing little about RAID configurations; is it > possible that some RAID configurations might exacerbate problems with > such a workload -- or that others might be more amenable to it? > If anything, a fast RAID controller will help reduce the lag that you get when the syncer does its periodic run. But beyond that, I can't think of anything that would cause problems. Scott