Date: Tue, 19 May 2009 13:00:02 -0700 From: Kip Macy <kip.macy@gmail.com> To: Dimitry Andric <dimitry@andric.com> Cc: freebsd-stable@freebsd.org, marck@rinet.ru, Pete French <petefrench@ticketswitch.com> Subject: Re: RFT: ZFS MFC Message-ID: <3c1674c90905191300y32710c9bnaa2001ad345d3b2a@mail.gmail.com> In-Reply-To: <4A130E66.9070903@andric.com> References: <E1M6TK0-0007v2-F8@dilbert.ticketswitch.com> <4A130E66.9070903@andric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dimitry@andric.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90905191300y32710c9bnaa2001ad345d3b2a>