From owner-freebsd-hackers Thu Aug 14 12:50:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08878 for hackers-outgoing; Thu, 14 Aug 1997 12:50:45 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA08873 for ; Thu, 14 Aug 1997 12:50:41 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA05609; Thu, 14 Aug 1997 15:50:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 14 Aug 1997 15:50 EDT Received: from lakes.dignus.com (lakes [10.0.0.3]) by ponds.dignus.com (8.8.5/8.7.3) with ESMTP id PAA00465 for ; Thu, 14 Aug 1997 15:27:33 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id JAA06376 for freebsd-hackers@freefall.cdrom.com; Thu, 14 Aug 1997 09:01:09 -0400 (EDT) Date: Thu, 14 Aug 1997 09:01:09 -0400 (EDT) From: Thomas David Rivers Message-Id: <199708141301.JAA06376@lakes.dignus.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: *really* slow rm on an async file system? Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If you remember; a few weeks ago (well, several now, actually) I initiated a discussion about 2.2.1 and news - how I had thought it expire was working slower in 2.2.1 then previous versions... At that time; there were several recommendations: 1) Mount the file system async (done) 2) Bump NBUF (now bumpped to 128) 3) the "control" group had received a massive swamp of control messages; making for quite a large directory (corrected by removing all the files in the /usr/spool/news/control directory.) This worked well for some time; but... the problem has resurfaced. So - I looked in /usr/spool/news/control - sure enough, there are quite a few files.... So - I did a "rm *" there; to removed them and rebuild my history file. It's now been 15 minutes; the "rm *" hasn't completed... (this is 2.2.1+ on a 386/33 w/ 8meg of memory... it's slow; but not *that* slow...) I can't stop the process (control-C doesn't get it), and, although an "echo *" worked in that directory just a second ago, it also hangs there now... Does this point to a potential buffer deadlock somewhere? I did a ps -gaxl, to see where rm was waiting; but it doesn't show up in the list... An interesting data point; I brought the machine to single-user and did an "ls -l" in my control directory. This bombed out due to lack of swap space... and echo * didn't complete either... so this could all simply be a swapping contention issue... Just F.Y.I. - - Dave Rivers -