From owner-freebsd-fs@FreeBSD.ORG Thu Apr 1 15:00:20 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43192106566B for ; Thu, 1 Apr 2010 15:00:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 311E18FC08 for ; Thu, 1 Apr 2010 15:00:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o31F0Jfv013968 for ; Thu, 1 Apr 2010 15:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o31F0JDO013967; Thu, 1 Apr 2010 15:00:19 GMT (envelope-from gnats) Date: Thu, 1 Apr 2010 15:00:19 GMT Message-Id: <201004011500.o31F0JDO013967@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Birgmeier Cc: Subject: Re: kern/145246: [ufs] dirhash in 7.3 gratuitously frees hashes when it shouldn't [regression] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Birgmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:00:20 -0000 The following reply was made to PR kern/145246; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/145246: [ufs] dirhash in 7.3 gratuitously frees hashes when it shouldn't [regression] Date: Thu, 01 Apr 2010 16:54:13 +0200 I believe that there should be some notion of "value" given to resources which may potentially be destroyed and recreated - computing the dirhash takes a lot of time (see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117954 ), and this work should not be thrown away lightly. (This is why dirhash exists in the first place.) Maybe the lowmem handler could be modified to only use the dirhash lowmem handler as a last resort. In my case, the kernel did not really seem to be that short on memory, as it has now been running with moderate to high load for 24 hours with the reversion to SVN rev 195783 for ufs_dirhash.c and dirhash.h. I have configured vfs.ufs.dirhash_maxmem=33554432 (32M) by the way. Compared to 1.25G, this is only 2.5%, so I believe not really something that's eating lots of memory. Regards, Martin