Date: Fri, 10 Oct 2008 13:07:43 +0200 From: Laszlo Nagy <gandalf@shopzeus.com> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Johan Hendriks <Johan@double-l.nl>, freebsd-questions@freebsd.org Subject: Re: [SOLVED] Re: 7.1 hangs, shutdown terminated Message-ID: <48EF377F.1030606@shopzeus.com> In-Reply-To: <20081010103753.GA30120@icarus.home.lan> References: <48EF14E1.9080808@shopzeus.com> <57200BF94E69E54880C9BB1AF714BBCB5DE18C@w2003s01.double-l.local> <48EF1C9C.3020201@shopzeus.com> <20081010091738.GA27925@icarus.home.lan> <48EF23CB.8020104@shopzeus.com> <20081010103753.GA30120@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> Firstly, I see a periodic(8) job that DOES use find -sx, which means > your attempt to track it down was faulty, and your syntax should have > been "find -sx /" not "find / -sx". See here: > > /etc/periodic/security/100.chksetuid: find -sx $MP /dev/null -type f \ > Thanks for clearing that out. :-) I did not remember what it was and failed to find it. > $MP == mountpoint, e.g. /, /var, or any other mounted filesystem. > > So, what you saw was the periodic check looking for setuid-root > binaries. > > Secondly, the kernel does not spawn userland processes like find(1). > > Thirdly, dirmem and dirmem_max are *pure* kernel things. What they do > is control the amount of memory used for directory structure caching; > rather than continually hit the disk every time and spend all that time > handling directory contents, the kernel can cache previously-fetched > contents in memory Now it stays this value constantly: vfs.ufs.dirhash_mem: 44306131 I think it is now caching everything. Thank you again, and sorry for the dumb questions. Laszlo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48EF377F.1030606>