Date: Sat, 06 Oct 2007 10:46:14 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS kmem_map too small. Message-ID: <20071006174614.E1D575B52@mail.bitblocks.com> In-Reply-To: Your message of "Fri, 05 Oct 2007 20:01:19 %2B0200." <20071005180119.GE98210@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
I have an athlon 64 x2 w/ 2GB of memory running in 64 bit mode.
The system dies in a couple of days. This machine does cvsup
mirroring every few hours + occassional portupgrade + makes.
But I have not been able to panic it deterministically. Its
loader.conf has
vfs.zfs.zil_disable=1
vfs.zfs.prefetch_disable=1
No other changes from defaults for anything relating to vm or
zfs.
The only way to make this more stable was to revert arc.c to
R1.10. There two differences: R1.11 arc_reclaim_needed()
returns 1 when 80% of kmem is used, while R1.10 does so at
50% of kmem. Second, R1.11 sets arc_c_max to 3/4 of
kmem_size while R1.10 sets it to 1/2 of kmem_size.
> > Tips on how to reproduce it? Make the kmem_map size small and set the
> > ARC's maximum size to be the same as it ? :)
>
> I'm not really interested in fixing configuration bugs, although we
> should do as much as we can to not allow bugus tunnings.
IMHO bad config can result in suboptimal performance but a
panic seems a bit drastic. Particularly as things that used
to work a month ago now don't. It would be nice if
configurations were sanitized during initialization or if
that is not possible take away a tuning knob altogether (or
leave it under debugging).
Still, fiddling with limits to make the panic go away seems
to somehow miss the point as I always worry it will show up
under other conditions. May be there a way to ensure that
kmem_map is never too small or may be zfs can reserve a few
resources for its own use so that it can get out of a tight
spot?
Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071006174614.E1D575B52>