From owner-freebsd-hackers Sat Aug 16 14:50:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12333 for hackers-outgoing; Sat, 16 Aug 1997 14:50:40 -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 OAA12328 for ; Sat, 16 Aug 1997 14:50:37 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA02525; Sat, 16 Aug 1997 17:50:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 16 Aug 1997 17: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 NAA13410; Sat, 16 Aug 1997 13:52:44 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id NAA03424; Sat, 16 Aug 1997 13:46:03 -0400 (EDT) Date: Sat, 16 Aug 1997 13:46:03 -0400 (EDT) From: Thomas David Rivers Message-Id: <199708161746.NAA03424@lakes.dignus.com> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.dignus.com!rivers Subject: Re: 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 > > > Perhaps it's worthwhile to indicate exactly what I've found, > >you may be absolutely correct - there could be a flaw in my logic: > > > >Deleting a file out of ~20,000 with 2.2.1, async mount, multiuser: 3-5 seconds > >Deleting a file out of ~10,000 with 2.2.1, sync mount, multiuser: 3-5 seconds > >Deleting a file out of ~10,000 with 2.2.1, sync mount, single user: 3-5 seconds > >Deleting a file out of ~300 with 2.2.1, sync mount, multiuser: 3-5 seconds > >Deleting all of ~300 with 2.1.7, sync mount, single user: 4 seconds > > > > > >> > >> Of course, my premises may be incorrect in this too. :0 > > > > It would be trivial for me to verify any slow or fast times - all > >I've got to do is make a big directory... seems that ~300 files is > >enough to run into whatever the problem may be... > > How many files are in the directory isn't important. What is important is > the size of the directory. You can have a 20MB directory and yet have only a > 100 files in it. There is code to free up unused space in directories, but > it only works if the free space is at the end. If the directory is large, > then it will take a large amount of time to search through it. > > -DG > Of course... that makes sense. It's possible that the directory shrunk when I did the last delete under 2.2.1 (before rebooting under 2.1.7) I hit that magic entry that caused this coalescing to occur - but I'd kinda think that would be unlikely... Do you think that could explain why 2.1.7 is so much faster than 2.2.1? I'll try and get a reliable reproduction of this one. - Dave R. -