Date: Mon, 18 Aug 1997 11:24:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hackers@freebsd.org Subject: Re: More info on slow "rm" times with 2.2.1+ Message-ID: <199708181824.LAA15497@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708181824.LAA15497>