From owner-freebsd-hackers Thu Aug 14 21:50:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06806 for hackers-outgoing; Thu, 14 Aug 1997 21:50:39 -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 VAA06789 for ; Thu, 14 Aug 1997 21:50:35 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA00058; Fri, 15 Aug 1997 00:50:02 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Aug 1997 00: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 XAA01801 for ; Thu, 14 Aug 1997 23:34:03 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id XAA08397 for freebsd-hackers@freefall.cdrom.com; Thu, 14 Aug 1997 23:23:07 -0400 (EDT) Date: Thu, 14 Aug 1997 23:23:07 -0400 (EDT) From: Thomas David Rivers Message-Id: <199708150323.XAA08397@lakes.dignus.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: More info on slow "rm" times with 2.2.1+. Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - I've (at last) replaced the 8meg 386 with a 24meg 486dx2-66. So, I expected to be able to simply mount that same file system, and quickly remove the files in /usr/spool/news/control. However - things are not going any faster... I have determined that it's not the argument processing; I can simply pick a single file to remove; issue: rm file and it takes upwards of 3 to 5 seconds and a *slew* of disk activity to accomplish the task... (recall, this is a miserable little IDE drive as well.. the 'rm' spends a lot of its time in biowait.) What I'm looking at now is a directory full of about 20,000 files, each of which is around 1024 bytes... (should be readily reproducible.) Then, simply pick a file to remove & wait... It appears to me that the remove is rewritting the entire directory structure (probably spanning more than one inode, since the file names are 7 bytes each - 20,000 * 7 is a few bytes :-) :-) Is this the case - and if so, is my achingly slow IDE I/O the real cause of the bottleneck in getting this data rewritten, or has something else happened in this area in 2.2.x? - Thanks - - Dave Rivers - p.s. We'll see what this 486 does to the "daily panics" when I can get news running again...