From owner-freebsd-hackers Mon Aug 18 11:31:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08262 for hackers-outgoing; Mon, 18 Aug 1997 11:31:22 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA08254 for ; Mon, 18 Aug 1997 11:31:18 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15497 for hackers@freebsd.org; Mon, 18 Aug 1997 11:24:54 -0700 From: Terry Lambert Message-Id: <199708181824.LAA15497@phaeton.artisoft.com> Subject: Re: More info on slow "rm" times with 2.2.1+ To: hackers@freebsd.org Date: Mon, 18 Aug 1997 11:24:53 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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.