Subject: bin/11094: lfs_cleanerd has memory leak
To: None <gnats-bugs@gnats.netbsd.org>
From: Bernd Sieker <bsieker@freenet.de>
List: netbsd-bugs
Date: 09/27/2000 15:13:21
>Number:         11094
>Category:       bin
>Synopsis:       lfs_cleanerd process occasionally grows huge on 3/4 full partitions
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 27 15:19:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Bernd Sieker
>Release:        NetBSD-1.5_ALPHA2 (sources from 2000-09-27)
>Organization:
Bernd Sieker
>Environment:
	
Asus P2B-B mainboard, Celeron-366, 64MB RAM, TekRAM-SCSI (siop driver)
NetBSD-1.5_ALPHA2 from 2000-09-27 sources.


>Description:
	I have a 2.8GB LFS partition on a SCSI disk. Occasionally, when copying
many small or few big files to it, the cleanerd process becomes more than 40 MB
and stays that big. Although it seems to do its job without crashing and
eventually gets completely paged out it still takes up precious swap space.

On small systems, however, this behaviour might lead to the cleaner daemon
running out of memory and being killed, to be restarted and maybe grow again.

Killing both lfs_cleanerd processes for the respective filesystem and remounting
it with the -u option (unmount first) starts a fresh pair of cleanerd and cures
the problem. Only remounting it starts a new pair of cleanerd without stopping the
old ones first, which might in itself be a bug.

>How-To-Repeat:
	I'm not sure if this will happen on all systems, but it might when
you fill up an LFS partition.
>Fix:

	Probably find a memory leak in the lfs_cleanerd source and fix it.

Workaround: kill the lfs_cleanerd processes for the offending filesystem and remount
if using: "mount -u <mountpoint>"

>Release-Note:
>Audit-Trail:
>Unformatted: