kern/145246: dirhash in 7.3 gratuitously frees hashes when it shouldn't

Martin Birgmeier martin.birgmeier at
Wed Mar 31 17:40:01 UTC 2010

>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
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 31 17:40:00 UTC 2010
>Originator:     Martin Birgmeier
>Release:        RELENG_7_3_0_RELEASE
MBi at home
FreeBSD gandalf.xyzzy 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 20:08:05 CET 2010     root at atpcdvvc.xyzzy:/usr/VOL/OBJ/FreeBSD/RELENG_7_3_0_RELEASE/src/sys/XYZZY  i386
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 , which is still unsolved and leads to several tens of seconds of complete freezes of the machine whenever the dirhash is (re-) computed.
Mirror the SVN repo (rsync:// on a FreeBSD 7.3 machine with 1.25 GiB of memory. Note: This does not succeed any more because the rsync server (on times out before the local dirhash can be created for the two directories in question.
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?


More information about the freebsd-bugs mailing list