Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Aug 1997 07:06:53 -0400 (EDT)
From:      Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
To:        ponds!lakes.dignus.com!rivers, ponds!aol.com!StevenR362
Cc:        ponds!freebsd.org!hackers
Subject:   Re: More info on slow "rm" times with 2.2.1+.
Message-ID:  <199708161106.HAA02927@lakes.dignus.com>

next in thread | raw e-mail | index | archive | help
> 
> In a message dated 97-08-15 08:44:13 EDT, ponds!rivers@dg-rtp.dg.com writes:
> 
> > Ah... I haven't seen my own follow ups yet; you may already know
> >  this... 
> >  
> >   But, apparently, it's 2.2.x that doesn't handle large directories
> >  very well - 2.1.7 seems to work like a champ.
> >  
> >   It was taking 3-5 seconds to remove a file in a 300-400 entry directory
> >  with 2.2.1.  It took only 3 seconds to remove all 300+ files with 2.1.7.
> >  [I booted up 2.1.7 with a fixit floppy, mounted the news partition
> >  and just did a "rm *" in control - *poof, they are all gone...]
> >  
> >   This is most definately a 2.2.x phenomenon...
> >  
> >  	- Dave Rivers -
> >  
>    If I read your previous posts correctly, then I think that your logical
> premises are incorrect and therefore your conclusion is false. :)
> 
> Your previous posts seemed to indicate that you tried doing an rm *
> in a 20,000 file directory.  You then aborted it when only 300-400 files
> were left and then tried deleteing individual files in this directory.  
  Yes - after many+ hours had passed :-)

>                                                                         Both
> of
> these operations were incredibly slow under 2.2.1, Correct?  You then
> rebooted under 2.1.7 and the same directory with 300-400 files was deleted
> quickly.  I posit that if you had rebooted to the same 2.2.1 kernel and then
> tried deleting the remaining 300-400 files it would have gone quickly as
> well.

 Another very good point... see below.  But, it's interesting; 
why do you believe a reboot would have improved things?  Are you
thinking along the lines of a flushed namei cache?

> 
> You might also have gotten the same effect by simply unmounting and
> remounting
> the filesystem or possibly just doing a couple of syncs at the command line.

 Ahh... very good point.  

 Just f.y.i. - I did unmount and mount the file system again, just
to ensure that async had any effect at all (which it didn't appear
to) but this was when the directory contained 20,000 files.   But, I
didn't clearly relate that...

 I did try to do a single-user delete (i.e. boot -s) under 2.2.1
when the directory had ~10,000 files - and still got the same slow "rm"
times (on a non-async file system at that point.)

 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...

> 
> STeve
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708161106.HAA02927>