From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 31 17:40:01 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95AD01065673 for ; Wed, 31 Mar 2010 17:40:01 +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 53C798FC18 for ; Wed, 31 Mar 2010 17:40:01 +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 o2VHe1JL054851 for ; Wed, 31 Mar 2010 17:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2VHe1jM054850; Wed, 31 Mar 2010 17:40:01 GMT (envelope-from gnats) Resent-Date: Wed, 31 Mar 2010 17:40:01 GMT Resent-Message-Id: <201003311740.o2VHe1jM054850@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Birgmeier Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB001065676 for ; Wed, 31 Mar 2010 17:30:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id C9F268FC22 for ; Wed, 31 Mar 2010 17:30:57 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o2VHUvm3016402 for ; Wed, 31 Mar 2010 17:30:57 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o2VHUv9U016401; Wed, 31 Mar 2010 17:30:57 GMT (envelope-from nobody) Message-Id: <201003311730.o2VHUv9U016401@www.freebsd.org> Date: Wed, 31 Mar 2010 17:30:57 GMT From: Martin Birgmeier To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/145246: dirhash in 7.3 gratuitously frees hashes when it shouldn't X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:40:01 -0000 >Number: 145246 >Category: kern >Synopsis: dirhash in 7.3 gratuitously frees hashes when it shouldn't >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 31 17:40:00 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Martin Birgmeier >Release: RELENG_7_3_0_RELEASE >Organization: MBi at home >Environment: FreeBSD gandalf.xyzzy 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 20:08:05 CET 2010 root@atpcdvvc.xyzzy:/usr/VOL/OBJ/FreeBSD/RELENG_7_3_0_RELEASE/src/sys/XYZZY i386 >Description: The new dirhash function ufsdirhash_lowmem() is called in low-memory situations. I have a KDE repository mirror on a machine with 1.25 GiB of memory, with 2 directories of each more than 10e6 entries. Due to memory pressure, the hashes are now freed multiple times even during a single subversion command, such that subversion exhibits extremely long waiting times and is nearly unusable. This is also due to bug http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117954 , which is still unsolved and leads to several tens of seconds of complete freezes of the machine whenever the dirhash is (re-) computed. >How-To-Repeat: Mirror the SVN repo (rsync://rsync.kde.org/svnmirror/) on a FreeBSD 7.3 machine with 1.25 GiB of memory. Note: This does not succeed any more because the rsync server (on rsync.kde.org) times out before the local dirhash can be created for the two directories in question. >Fix: Probably go back to the old dirhash behavior (7.2), or free dirhashes only as last resort in low-mem situations. Note: I never had memory problems in 7.2 with the old dirhash behavior, so clearly there was still enough memory (to be gotten from somewhere else, probably). Can I revert the dirhash changes by just reverting ufs_dirhash.c? >Release-Note: >Audit-Trail: >Unformatted: