From owner-freebsd-stable@FreeBSD.ORG Thu May 8 13:18:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39FFF1065678; Thu, 8 May 2008 13:18:25 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id E85598FC1B; Thu, 8 May 2008 13:18:24 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-0006nx-KZ; Thu, 08 May 2008 14:18:23 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-000Ec3-HG; Thu, 08 May 2008 14:18:23 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-0001c3-GO; Thu, 08 May 2008 14:18:23 +0100 To: freebsd-stable@freebsd.org, ivoras@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Thu, 08 May 2008 14:18:23 +0100 Cc: Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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: Thu, 08 May 2008 13:18:25 -0000 > Couple of ideas: > > - Don't use "128" as the default since it will lead people to think > there's an 8-bit quantity behind the setting (and subsequently develop > weird theories about how the setting works), when it isn't so. Use 100 > or 1000. Are you sure it isn't an 8 bit value underneath ? I know it is defined as an int, but trying to set it to anything outside the range 0-255 results in it wrapping round (e.g. you try making the defalt 1000 and it comes out as 232). I havent looked in detail as *why* thats happening, but it certainly behaves like it is 8 bits, hence my choice of default. > - Why not go all the way and make another argument or a switch that will > specify exactly which drive to prefer, so you could say "prefer N", > where N is any drive / component, not only the one with lowest/highest > priority? This is slightly more complex and will probably require an > addition to the metadata (which isn't complicated but you have to be > careful) and a workaround so the old semantics of the "plain" setting is > supported. I thought about that, but the priority scheme doesnt just specify one drive, it specifies a whole set - effectively you find the highest usable drive. Just defining one isn't sufficient, you need to have a defined way of falling back if that one isn't active. Secondly I want to avoid having to search the whole list event time. Currently the list of drives is created in priority order (no matter what the balance algorithm) so the 'prefer' algorithm simply traverses the list looking for the first active drive. I wanted to keep that and thus simply convert the list to a tailq so I can traverse it both ways, rather than having to seek the whole list every time. It keeps the code as close to the current code as possible. I'll get an initial version out and then maybe take a look at doing something more complex though. cheers, -pete.