From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 22:15:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147D824D for ; Thu, 28 Nov 2013 22:15:17 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD3521848 for ; Thu, 28 Nov 2013 22:15:16 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rASMFDF5050936; Thu, 28 Nov 2013 15:15:13 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rASMFBlu050933; Thu, 28 Nov 2013 15:15:11 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 28 Nov 2013 15:15:11 -0700 (MST) From: Warren Block To: =?ISO-8859-15?Q?Szalai_Andr=E1s?= , Schaich Alonso Subject: Re: gmirror: writes are faster than reads In-Reply-To: <20131128220305.e715adb95b16f494224052f5@fastmail.fm> Message-ID: References: <5297ABD5.5060504@gmail.com> <20131128220305.e715adb95b16f494224052f5@fastmail.fm> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 28 Nov 2013 15:15:13 -0700 (MST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 22:15:17 -0000 On Thu, 28 Nov 2013, Schaich Alonso wrote: > Modern HDDs have both Command Queuing and Excessive Cache Memory. Using them > a spindle disk can cache multiple write requests and do them all in one > revolution. While multiple read requests can also be done at once chances > are the on-disk cache is not usefull (because the requested data is only > resident if it was accessed short before, and then it's also availible in > the kernel's larger Filesystem/GEOM caches which reside in main memory and > were consulted prior to disk accesses) and the GEOM layer might not have > issued them yet. IIRC the UFS subsystem will perform no read requests smaller > than 512kB by default, which means it does some readahead just in case the > issuing application wants to read more data soon - however you have used read > blocks which are exact multiples of 512kB, so there is no gain in this. > > readahead is the buzzword for tuning large sequencial reads, and I had thought > there was a sysctl for it, though I can't find it now. gmirror also has four different load-balancing algorithms which can affect read and write speeds.