From owner-freebsd-current@FreeBSD.ORG Fri Apr 28 00:43:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA8D16A400 for ; Fri, 28 Apr 2006 00:43:20 +0000 (UTC) (envelope-from brian@aljex.com) Received: from s1tank.virtdom.com (s1tank.virtdom.com [216.240.101.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 677BF43D4C for ; Fri, 28 Apr 2006 00:43:20 +0000 (GMT) (envelope-from brian@aljex.com) Received: (qmail 27389 invoked by uid 89); 28 Apr 2006 01:31:02 -0000 Received: from ool-44c5ba23.dyn.optonline.net (HELO venti) (brian@aljex.com@68.197.186.35) by s1tank.virtdom.com with SMTP; 28 Apr 2006 01:31:02 -0000 Message-ID: <02c301c66a5c$bafc7300$6500000a@venti> From: "Brian K. White" To: References: <20060427160536.M96305@atlantis.atlantis.dp.ua> <20060427181226.GA66431@xor.obsecurity.org> <44510CBE.6050102@sd2i.com> <20060427183541.GA67363@xor.obsecurity.org><445118C8.7020603@sd2i.com> <44511E27.2070101@chillt.de> Date: Thu, 27 Apr 2006 20:42:47 -0400 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Subject: Re: RELENG_4 -> 5 -> 6: significant performance regression 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: Fri, 28 Apr 2006 00:43:20 -0000 ----- Original Message ----- From: "Bartosz Fabianowski" To: Cc: Sent: Thursday, April 27, 2006 3:40 PM Subject: Re: RELENG_4 -> 5 -> 6: significant performance regression >> You wrote that Giant is needed in 6.0 and now you write it has been >> removed. > > In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not > normally required, making file system operations faster. When you enable > QUOTA, you basically get back to the 4.x behavior where Giant is needed > for each write. This is why in 6.x UFS will normally be faster but if you > enable QUOTA, you lose the newly gained performance again. In that case the test was correct the question stands at least on that point. If quota isn't mpsafe yet, that's fine. It just means that performance should still be only about the same as on 4 while quota is enabled. Removing a feature you had before is no answer to this question. Removing an expensive new feature that didn't exist before could be. Is it maybe simply some expected/known extra overhead that is ok because it's understood that it's only for a while, while mpsafe quota gets polished and no one is expected to switch production boxes over until after? And once we have mpsafe quota we'll have a faster fs that still delivers the same features? Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!