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