Date: Wed, 19 Dec 2007 02:19:28 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David G Lawrence <dg@dglawrence.com> Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds Message-ID: <20071219020952.A34422@delplex.bde.org> In-Reply-To: <20071218144133.GT25053@tnn.dglawrence.com> References: <D50B5BA8-5A80-4370-8F20-6B3A531C2E9B@eng.oar.net> <20071217102433.GQ25053@tnn.dglawrence.com> <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> <20071218144133.GT25053@tnn.dglawrence.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Dec 2007, David G Lawrence wrote: >> Thanks. Have a kernel building now. It takes about a day of uptime >> after reboot before I'll see the problem. > > You may also wish to try to get the problem to occur sooner after boot > on a non-patched system by doing a "tar cf /dev/null /" (note: substitute > /dev/zero instead of /dev/null, if you use GNU tar, to disable its > "optimization"). You can stop it after it has gone through a 100K files. > Verify by looking at "sysctl vfs.numvnodes". Hmm, I said to use "find /", but that is not so good since it only looks at directories and directories (and their inodes) are not packed as tightly as files (and their inodes). Optimized tar, or "find / -type f", or "ls -lR /", should work best, by doing not much more than stat()ing lots of files, while full tar wastes time reading file data. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071219020952.A34422>