From owner-freebsd-current@FreeBSD.ORG Tue Apr 28 10:27:25 2009 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 8C6F9106566B for ; Tue, 28 Apr 2009 10:27:25 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 553A88FC1D for ; Tue, 28 Apr 2009 10:27:25 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n3SARNL1077741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 03:27:24 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49F6DA03.2010404@FreeBSD.org> Date: Tue, 28 Apr 2009 03:27:15 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ivan Voras References: <49F6CA67.6030302@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Improving geom_mirror(4)'s read balancing 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: Tue, 28 Apr 2009 10:27:25 -0000 Ivan Voras wrote: > Maxim Sobolev wrote: > >> The patch is available here: >> http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like to >> get input on the functionality/code itself, as well on what is the best >> way to add this functionality. Right now, it's part of the round-robin >> balancing code. Technically, it could be added as a separate new >> balancing method, but for the reasons outlined above I really doubt >> having "pure" round-robin has any practical value now. The only case >> where previous behavior might be beneficial is with solid-state/RAM >> disks where there is virtually no seek time, so that by reading close >> sectors from two separate disks one could actually get a better speed. >> At the very least, the new method should become default, while "old >> round-robin" be another option with clearly documented shortcomings. I >> would really like to hear what people think about that. > > Have you perhaps seen this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885 > > I'm using the patch in the PR and it helps a bit, similar to what you > have seen. Pawel is silent about the issue so I guess it can also be > taken as silent approval :) Oh, great! I am curious as to if there is any background behind "distance to use delay" metric? To me it seems the current number of outstanding requests is much more important when selecting between disk X and disk Y. I am not a storage expert, so that I could be wrong though. One way or another the load-balancing has be improved and the new more intelligent scheduling IMHO should be the default one. -Maxim