From owner-freebsd-stable@FreeBSD.ORG Sat Jan 9 01:32:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 683CD106566B for ; Sat, 9 Jan 2010 01:32:25 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2919B8FC12 for ; Sat, 9 Jan 2010 01:32:24 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id 23FD85CB8EB; Sat, 9 Jan 2010 12:08:40 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: * X-Spam-Status: No, score=1.9 required=10.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.20.30.104] (60.218.233.220.static.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 444CD5CB8BB for ; Sat, 9 Jan 2010 12:08:36 +1100 (EST) Message-ID: <4B47DC94.7020202@modulus.org> Date: Sat, 09 Jan 2010 12:32:04 +1100 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001080831w375d158fu5b1996ee58cb0f8d@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 01:32:25 -0000 Ivan Voras wrote: > It is true that ZFS in theory doesn't do very well with random writes of > any kind - the kind that torrent clients do should actually be the worst > case for ZFS, *but*, this very much depends on the actual workload. ZFS has aggressive read-ahead for sequential read-aheads, so its worth noting that the performance problem can be mitigated by having lots of RAM free for read-ahead, as well as multiple vdevs in the zpool (so that it can be seeking all disks at once) - Andrew