From owner-freebsd-fs@FreeBSD.ORG  Tue Sep 13 09:56:49 2011
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E82B41065675;
	Tue, 13 Sep 2011 09:56:49 +0000 (UTC)
	(envelope-from mark@exonetric.com)
Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161])
	by mx1.freebsd.org (Postfix) with ESMTP id 74CB58FC12;
	Tue, 13 Sep 2011 09:56:49 +0000 (UTC)
Received: from [172.16.0.129] (94-30-105-106.xdsl.murphx.net [94.30.105.106])
	by relay0.exonetric.net (Postfix) with ESMTP id 5010A57013;
	Tue, 13 Sep 2011 10:38:21 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1244.3)
From: Mark Blackman <mark@exonetric.com>
In-Reply-To: <j4n7tn$r1u$1@dough.gmane.org>
Date: Tue, 13 Sep 2011 10:38:20 +0100
Message-Id: <B5CD3F95-759C-426B-BA90-F0046C58C0A8@exonetric.com>
References: <freemail.20110912210908.38291.2@xmldata09.freemail.hu>
	<alpine.GSO.2.01.1109121428570.12948@freddy.simplesystems.org>
	<j4n7tn$r1u$1@dough.gmane.org>
To: Ivan Voras <ivoras@freebsd.org>
X-Mailer: Apple Mail (2.1244.3)
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-fs@freebsd.org
Subject: Re: ZFS-lighttpd2-sendfile, too high IO
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 09:56:50 -0000


On 13 Sep 2011, at 10:31, Ivan Voras wrote:
>> 
>> Zfs reads whole 128K blocks (or whatever the filesystem blocksize is) at
>> a time.  It does not read partial blocks from underlying storage. This
>> makes it very expensive to perform many small read accesses if the reads
>> are not subsequently cached in the ARC.
> 
> Yes!
> 
> Which makes it particularly "interesting" if you try to run a database
> on it while forgetting to reset the block size to e.g. 8K before the
> database is initialized - you get 16x more IO than you expected.
> 

Yes, I got this but what can you do if the database has already been 
initialized? I'm guessing the only realistic option is to set the block
size, then copy the database files to a new directory and rename the old
and new directories so the new directory is the database store.

Perhaps you need to use an entirely new dataset?

- Mark