ZFS kmem_map too small.

Guy Brand gb at isis.u-strasbg.fr
Mon Oct 8 13:28:36 PDT 2007


Pawel Jakub Dawidek (pjd at freebsd.org) on 08/10/2007 at 14:15 wrote:

> Can you guys retry with this patch:
> 
> 	http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch
> 
> It's a hack, yes, but allows to mitigate the problem quite well. I'm
> looking for a solution that can be used for 7.0 before we find a better
> fix.
> 
> BTW. To use ZFS you _must_ increase vm.kmem_size/vm.kmem_size_max.
> If you have the problem discussed here and you're using standard values,
> please retry with vm.kmem_size/vm.kmem_size_max set to at least 600MB in
> /boot/loader.conf.

  Hi,

  
  On a Lenovo X61s from yesterday (FreeBSD 7.0-CURRENT #1: Sun Oct  7
  21:55:14 CEST 2007) with

	hw.model: Intel(R) Core(TM)2 Duo CPU     L7500  @ 1.60GHz
	hw.physmem: 2091008000
	hw.machine_arch: i386
	hw.realmem: 2104164352

  and a single zpool containing ad4s2 slice (all FS except /). I tuned
  vm.kmem_size and ran ad vitam:

    - vt0: rsync /usr/src /tmp/. && rm -rf /tmp/src
    - vt1: dd if=/dev/zero of=/tmp/file bs=1k count=1000000

  The kernel panics until vm.kmem_size/vm.kmem_size_max is set to
  671088640 where I could have both loops running for 3 hours. But
  then the system was hanging: rsync and dd seem stopped in their
  execution. This was confirmed on another term (load of 0). Any
  attempt to R/W from the poll (touch/ls) hangs the terminal. I could
  still log in to a term, but reboot/shutdown failed.

  I applied your patch and re-run the tests. After eight hours, the
  kernel is still up and usable. Thanks Pawel.

> I'm not sure if it's not too late to ask re@ about increasing the
> default kmem size at least on amd64. ~300MB we have there is silly
> small.

  Default vm.kmem_size value is 335544320 on my laptop: a portsnap
  fetch + extract from scratch panics with kmem_map too small.

-- 
  bug



More information about the freebsd-fs mailing list