Packet loss every 30.999 seconds

[Alfred Perlstein]

* David G Lawrence <dg at dglawrence.com> [071219 09:12] wrote:
> > >Try it with "find / -type f >/dev/null" to duplicate the problem  
> > >almost
> > >instantly.
> > 
> > I was able to verify last night that (cd /; tar -cpf -) > all.tar would
> > trigger the problem.  I'm working getting a test running with
> > David's ffs_sync() workaround now, adding a few counters there should
> > get this narrowed down a little more.
> 
>    Unfortunately, the version of the patch that I sent out isn't going to
> help your problem. It needs to yield at the top of the loop, but vp isn't
> necessarily valid after the wakeup from the msleep. That's a problem that
> I'm having trouble figuring out a solution to - the solutions that come
> to mind will all significantly increase the overhead of the loop.
>    As a very inadequate work-around, you might consider lowering
> kern.maxvnodes to something like 20000 - that might be low enough to
> not trigger the problem, but also be high enough to not significantly
> affect system I/O performance.

I apologize for not reading the code as I am swamped, but a technique
that Matt Dillon used for bufs might work here.

Can you use a placeholder vnode as a place to restart the scan?
you might have to mark it special so that other threads/things
(getnewvnode()?) don't molest it, but it can provide for a convenient
restart point.

-- 
- Alfred Perlstein