From owner-svn-src-all@FreeBSD.ORG Wed Jan 6 18:40:07 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6191065672; Wed, 6 Jan 2010 18:40:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6725D8FC08; Wed, 6 Jan 2010 18:40:05 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so875749eye.9 for ; Wed, 06 Jan 2010 10:39:55 -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=lGUiaXoEVHsC85jyvk7VhW8BwoQ9oBz7pggV+e/Syic=; b=lL3xRIajPWUeH/9lJdsrtZioMtFjDJACzaui9fmDJvZR6mGEUzHozvq2nm+vmrYfA7 KyObkcU1txLe7LzOFxh6P2rEv1QoQpX9Zd6WKJb7+J/9KgIFuJVxXuORQeFcz3y8F4n3 Kes2oqxOU8IJnf5+7kAMauiQrAPK3UB0it0jM= 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=SaSmg0am79CpnYYlpfZW7eVdo1P5Hh/eEYhLToJzUZN1oc43pnwjyA4uFO6F5bC6l7 2EfhLjjyOB4ZuISP42iAQ34wyVEa9UPewoYV+sVOoiQiKbUC4XZOCXm7YWSGJ0Dpk7jR /Ps2EeQcRMUCjoorI2EEObT+10CnaPRR+35/c= Received: by 10.216.85.134 with SMTP id u6mr2724995wee.213.1262803195320; Wed, 06 Jan 2010 10:39:55 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([72.14.240.162]) by mx.google.com with ESMTPS id g9sm54973359gvc.25.2010.01.06.10.39.53 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Jan 2010 10:39:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4B44D8FA.2000608@FreeBSD.org> Date: Wed, 06 Jan 2010 20:39:54 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Ivan Voras References: <201001061712.o06HCICF087127@svn.freebsd.org> <9bbcef731001060938k2b0014a2m15eef911b9922b2c@mail.gmail.com> In-Reply-To: <9bbcef731001060938k2b0014a2m15eef911b9922b2c@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r201658 - head/sbin/geom/class/stripe X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:40:07 -0000 Ivan Voras wrote: > 2010/1/6 Alexander Motin : >> Author: mav >> Date: Wed Jan 6 17:12:18 2010 >> New Revision: 201658 >> URL: http://svn.freebsd.org/changeset/base/201658 >> >> Log: >> Increase default block size from 4K to 64K. It was reduces 6 yeard ago, >> when trees were big and FAST mode was enabled by default. >> >> So small block size doesn't benefits linear I/O operations in FAST and >> significantly slowdowns in ECONOMIC (default) mode. For single stream random >> I/Os so small block doesn't give much benefits, as access time is usually >> bigger then transfer time there. Same time it requires all heads to seek >> together for every single request, reducing performance on parallel load. > > I think there was one more reason - though I'm not sure if it is still > valid because of your current and future work - the MAXPHYS > limitation. If MAXPHYS is 128k, with 64k stripes data was only to be > read from maximum of 2 drives. With 4k stripes it would have been read > from 128/4=32 drives, though I agree 4k is too low in any case > nowadays. I usually choose 16k or 32k for my setups. While you are right about MAXPHYS influence, and I hope we can rise it not so far, IMHO it is file system business to manage deep enough read-ahead/write-back to make all drives busy, independently from MAXPHYS value. With small MAXPHYS value FS should just generate more requests in advance. Except some RAID3/5/6 cases, where short writes ineffective, MAXPHYS value should only affect processing overhead. I've chosen 64K as level, where most of modern HDDs/SSDs reaching close to maximum performance, where large request splitting with present MAXPHYS is still possible, where medium request splitting not very reduces performance on parallel load, and where interrupt rate is not so high. Definitely it is question of personal tuning, but I think it is a reasonable default. -- Alexander Motin