From owner-svn-src-stable-8@FreeBSD.ORG Sun Dec 13 02:20:49 2009 Return-Path: Delivered-To: svn-src-stable-8@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21B11065670; Sun, 13 Dec 2009 02:20:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 992488FC25; Sun, 13 Dec 2009 02:20:48 +0000 (UTC) Received: by fxm28 with SMTP id 28so468010fxm.13 for ; Sat, 12 Dec 2009 18:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=SHdI51NWEUx5dfd3YibMxYoPBJ7SfAl4VxtsUNIhgUk=; b=pAO98V3S2jJvhGefViD/nt98MwW6+MNPGlZ916HAfTIfqY11mBXjj7QZ2y+9gfq2ge C0zPZjiu69+qmb2Lto+uouUKYNQwIG2nc83JvvnNyjGO/9Qlxufr0W2NLbZh+slUxegu LU8IVRO6nvDPQUCdKeLIU7c9wNYbHRZsf7A60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=uXVpCWXbucrIsU9IcllitTqI/h1p5wu5E9pSAfRjmE9He33ks1V4Sqf0BYScRTOIfS ZTi2udVTh/LAgQHtkdwQCYPpIbkRlAOgeHNT97/H++0XbPhy4htFmGFF5FQd9zU+s3am mFFhPdJfHgrhUS6P1vIy36Kn1VZKmadS+mJVs= Received: by 10.223.14.145 with SMTP id g17mr3577675faa.51.1260670847345; Sat, 12 Dec 2009 18:20:47 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm1126065fxm.0.2009.12.12.18.20.45 (version=SSLv3 cipher=RC4-MD5); Sat, 12 Dec 2009 18:20:46 -0800 (PST) Sender: Alexander Motin Message-ID: <4B244F7C.1070205@FreeBSD.org> Date: Sun, 13 Dec 2009 04:20:44 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Will Andrews References: <200912102351.nBANpOKc078607@svn.freebsd.org> <4B21A4B9.3070005@FreeBSD.org> <20091213015909.GB27552@cephei.firepipe.net> In-Reply-To: <20091213015909.GB27552@cephei.firepipe.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-stable-8@FreeBSD.org, svn-src-stable@FreeBSD.org Subject: Re: svn: stable/8/sbin/geom/class/mirror X-BeenThere: svn-src-stable-8@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 8-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 02:20:49 -0000 Will Andrews wrote: > On Thu, Dec 10, 2009 at 05:47:37PM -0800, Maxim Sobolev wrote: >> Alexander Motin wrote: >>> Author: mav >>> Date: Thu Dec 10 23:51:24 2009 >>> New Revision: 200373 >>> URL: http://svn.freebsd.org/changeset/base/200373 >>> >>> Log: >>> MFC r200282, r200290: >>> Change gmirror default balance algorithm from "split" to improved "load". >>> "split" is very ineffective for devices with rotating media as HDDs. >>> To be effective, it needs that transfer time reduction due to block >>> splitting was bigger then access time increase due to non-sequential >>> access. For modern HDDs I was able to reproduce it only with read sizes >>> of 2MB and above, which is almost not applicable in real life. >>> "load" algorithm same time is more universal and effective now. >> The other problem with real hard drives is that they usually read much >> more data than requested. Some suggest that they read as much as one >> track each time the data is not in cache even if one sector has been >> requested, therefore splitting request of any reasonable size is >> meaningless, as it would simply cause both drives to load essentially >> the same data, wasting half of available I/O bandwidth and in addition >> you cause both heads to do seek, which makes it even worse. > > Indeed. I think the benchmarks speak for themselves. The new algorithm > results in much lower average I/O service time, due to the seek time > reduction by dispatching read requests to providers according to the known > distance from the request, and also reduced by taking advantage of the disk > cache. The disk cache size probably affects how close the requests need to > be for optimal selection, so perhaps a sysctl is warranted to allow > administrative adjustment of this value from mav@'s default of 1MB. I've took 1MB not from cache, but from track size. I've divided read speed of modern drive on number of RPMs. I doubt that disk will read more then one track ahead, and same time it is quite probable to read whole current track, as head is already there and caches are quite large now. Sure it can be made tunable, but I think it is not very important, if you won't build mirror of floppy disks. Even in worst case current algorithm will give load disbalance no more then 1 request, as distance is only a hint, not a strict rule. -- Alexander Motin