[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: More info on slow "rm" times with 2.2.1+
From:       Terry Lambert <terry () lambert ! org>
Date:       1997-08-18 18:24:53
[Download RAW message or body]

>  Ok - I can buy that - the last block will take longest to delete
> (since you have to skip over the previous, un-coalesced, entries...)
> 
>  But - I'm not sure that explains why deleting the last 300 files
> would have (3*300) 900 seconds with 2.2.1 in this situation, where
> it only took 2.1.7 3 seconds.  Just from listening to the disk
> and watching I/O I can see that 2.2.1 is doing an *awful* lot of 
> I/O 2.1.7 didn't do... could there be something in this locking?

Because the logic in VOP_LOCK is inverted, and you are taking a
sleep (mostly) on each delete, which in turn results in a context
switch.  That's like saying "usleep( 10000);" between each one.
The need for it comes from vclean() (which, as I've said before,
must die).

People think the BSD4.4-Lite2 locking stuff is an improvement; it
is, but only from the API perspective.  The inverted lock ordering
in VOP_LOCK specifically for the vnode reclaimation process is
bogus as hell.  So is the VOP_ADVLOCK calling needing to be
implemented per FS.  NFS Server locking requires a delay between
local assertion and local coelescing to allow for a failed attempt
at remote assertion to trigger a local backout, which can't happen
after a coelesce, so this is only going to become more obvious
as time goes on.  I'm patient...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

[prev in list] [next in list] [prev in thread] [next in thread]