RFT: ZFS MFC
kip.macy at gmail.com
Tue May 19 20:00:06 UTC 2009
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.
On Tue, May 19, 2009 at 12:54 PM, Dimitry Andric <dimitry at andric.com> wrote:
> On 2009-05-19 19:41, Pete French wrote:
>> 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. :)
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
More information about the freebsd-stable