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