vm.kmem_size for stability to avoid kernel panics?
Jeremy Chadwick
freebsd at jdc.parodius.com
Fri Sep 17 08:39:53 UTC 2010
On Fri, Sep 17, 2010 at 11:24:30AM +0300, Andriy Gapon wrote:
> on 17/09/2010 09:12 Jeremy Chadwick said the following:
> > # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA
> > # on 2010/05/24.
> > # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html
> > vfs.zfs.zio.use_uma="0"
>
> I think that that commit was reverted and zero is a default value now.
Yeah, it was.
However, because it's impossible to determine in every single case what
the kernel build date is on a readers' machine (ex. people who search
Google, find the mailing list post, etc.), I mention it as a safety
net.
I should have mentioned this one as well (I don't include it in our
loader.conf because our RELENG_8 systems all have kernels built after
the below commit) -- the recent change of vfs.zfs.vdev.max_pending's
value, from 35 to 10:
vfs.zfs.vdev.max_pending="10"
And that's based on this commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c#rev1.4.2.1
<soapbox>
I say this while on a soapbox, but I'm trying to do so politely.
This is why I continue to harp/rant/whine about the need for better
communication about all the changes that happen, especially in ZFS, to
the RELENG_x (non-HEAD) branches. That means literally every commit.
Most users/admins do not follow commits or mailing lists, instead
resorting to Google to find solutions, etc... I also know that
committers/engineers can't dedicate that amount of time either. I
just wish we could find a compromise that works well. A lot of
places use blogs for this task.
</soapbox>
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-fs
mailing list