From owner-freebsd-stable@FreeBSD.ORG Tue May 19 19:54:14 2009 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 D3B68106564A for ; Tue, 19 May 2009 19:54:14 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9590C8FC0A for ; Tue, 19 May 2009 19:54:14 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:1dc8:f31e:251e:727c] (unknown [IPv6:2001:7b8:3a7:0:1dc8:f31e:251e:727c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D94A75C42; Tue, 19 May 2009 21:54:13 +0200 (CEST) Message-ID: <4A130E66.9070903@andric.com> Date: Tue, 19 May 2009 21:54:14 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, marck@rinet.ru Subject: Re: RFT: ZFS MFC 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: Tue, 19 May 2009 19:54:15 -0000 On 2009-05-19 19:41, Pete French wrote: >> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 > > Thanks - am going to gve this a try later. Preseumably if I leave the > pool at the revision it is currently on then I can revert back easily ? I'll just repeat what Kip told us, "The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time." That said, zpool(1M) tells: zpool upgrade [-V version] -a | pool ... Upgrades the given pool to the latest on-disk version. Once this is done, the pool will no longer be accessible on systems running older versions of the software. and later on: -V version Upgrade to the specified version. If the -V flag is not specified, the pool is upgraded to the most recent version. This option can only be used to increase the version number, and only up to the most recent version supported by this software. E.g. you can upgrade pools to ZFS v13, but there's no way back. If you don't upgrade your pool, it should not destroy anything (but don't count on it!), but you won't be able to test any new features either... > Also, is this the version which no longer requires any tuning parameters > in loader.conf ? That would be extermely interesting! As far as I know, the tuning stuff still applies, especially for i386. On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. So please test, and let us know your findings. :)