From owner-freebsd-stable@FreeBSD.ORG Tue May 19 20:00:05 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 D9769106566C for ; Tue, 19 May 2009 20:00:05 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5E98FC16 for ; Tue, 19 May 2009 20:00:05 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so13556eyd.7 for ; Tue, 19 May 2009 13:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/Pm07jd2wA+15kMWTfwivoGM1H3pB73EcIerIASxa6c=; b=eQX/oAi482SHk+MzlZ1BlRpNhUHLdjJ6sydDQV39gYLgcHNVqhIPgaVLV9CUlHagOy jZOfJ8czw4BgSgs4N6N6RInM+26iTkQBNQxqyaK8tkdF0Qbz4TSmpM2HCSfIKgaXVkEh ffVBYP8JqjgmvUYtzSggALEA/gVRThH4sz3h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GiZBNr6y1bWnGmygStfuF31pCvR3kL6slrBDtyL6WSxMu734N7odyii6IGTawHDk6G cAHA6u6+CLj3u7OZT50JgCUO51qo2fR9PrB6DvTmmyK1plZYpa1QeE7RFhfa+eHD/u62 Ac0uy1uGSUHIhiWvfCOm9bv+ZKCfQG8cKDkSE= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.216.35.204 with SMTP id u54mr105860wea.182.1242763202777; Tue, 19 May 2009 13:00:02 -0700 (PDT) In-Reply-To: <4A130E66.9070903@andric.com> References: <4A130E66.9070903@andric.com> Date: Tue, 19 May 2009 13:00:02 -0700 X-Google-Sender-Auth: 087c74d72bca7d46 Message-ID: <3c1674c90905191300y32710c9bnaa2001ad345d3b2a@mail.gmail.com> From: Kip Macy To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, marck@rinet.ru, Pete French 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 20:00:06 -0000 Many people are happily running an old pool with the new code. I have done that in a VM and run load over it just to be certain. The tuning still applies to i386. On amd64 vm backpressure works, but may actually be too aggressive - shrinking the ARC in favor of the inactive pages queue. Cheers, Kip On Tue, May 19, 2009 at 12:54 PM, Dimitry Andric wrote= : > 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: > > =A0 =A0 =A0 zpool upgrade [-V version] -a | pool ... > > =A0 =A0 =A0 =A0 =A0 Upgrades the given pool to the latest on-disk version= . Once this is > =A0 =A0 =A0 =A0 =A0 done, the pool will no longer =A0be =A0accessible =A0= on =A0systems =A0running > =A0 =A0 =A0 =A0 =A0 older versions of the software. > > and later on: > > =A0 =A0 =A0 =A0 =A0 -V version =A0 =A0Upgrade =A0to =A0the specified vers= ion. If the -V flag is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not specified, the =A0poo= l =A0is =A0upgraded =A0to =A0the =A0most > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 recent =A0version. =A0Thi= s =A0option =A0can =A0only =A0be used to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 increase the version numb= er, and only up to the =A0most > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 recent version supported = by this software. > > E.g. you can upgrade pools to ZFS v13, but there's no way back. =A0If 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 warni= ng: > > ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable beha= vior. > =A0 =A0 =A0 =A0 =A0 =A0 Consider tuning vm.kmem_size and vm.kmem_size_max > =A0 =A0 =A0 =A0 =A0 =A0 in /boot/loader.conf. > > So please test, and let us know your findings. :) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke