From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 18:18:23 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D05C616A46B; Sat, 6 Oct 2007 18:18:23 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id A3BF313C4C1; Sat, 6 Oct 2007 18:18:23 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id E1D575B52; Sat, 6 Oct 2007 10:46:14 -0700 (PDT) To: Pawel Jakub Dawidek In-reply-to: Your message of "Fri, 05 Oct 2007 20:01:19 +0200." <20071005180119.GE98210@garage.freebsd.pl> Date: Sat, 06 Oct 2007 10:46:14 -0700 From: Bakul Shah Message-Id: <20071006174614.E1D575B52@mail.bitblocks.com> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS kmem_map too small. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2007 18:18:23 -0000 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!