Re: threaded fs'es was Re: native win32 aufs

Kevin Littlejohn wrote:

> Ok. Is "one write per open fd" something we can rely on forever?

Never. The Squid state machine issues writes as soon as the needed
amount of data is there. It does not care when the write finishes.

> Likewise for reads? I agree, if that's the case, then it's safe
> - but I'm not convinced that'll always be the case?

Reads I am not sure about. The aufs code currently does not handle
paralell reads, but maybe the state machine can issue them if there is
multiple clients attached... but I think each reading client opens the
file separately..

> In particular, do range requests affect this at all

Nope.

> and will there be any aggregation of multiple clients into a
> single open fd anytime? Do we want to try and code for this
> behaviour (gack, what am I getting myself in for)?

Writes: no, but the Squid state machine issues writes in parallell to
the FS. aufs queues the writes to only have one async-io write request
at a time per fd.

Reads: probably not, but I am not 100% sure..

> Hrm. Possibly... It's a lot of extra ops to dodge a context switch, tho -
> especially given the only two places the lock is held besides that one are
> trivially quick ops. When does this thing trigger in actual use?

All I know is that it does get triggered. There was some bugs in early
implementations of request_queue2...

> pthread_mutex_trylock always feels a touch "hit'n'miss" to me - if it happens
> we're dealing with another request atm, then no matter how quickly that
> request is dealt with, we drop back to the failover thing. A sequence of bad
> timing breaks, and it looks like we're overloaded, regardless of how quickly
> requests are being dealt with. In fact, the quicker requests are dealt with,
> the more likely this is to trigger, as we're spending more time proportionally
> removing done requests from the queue...

pthread_mutex_trylock is a "hit'n'miss" thing. But the important thing
here is total queue latency, not how quickly the reques gets into the
active queue. So it is sufficient to get the request into the queue
quickly enough so it gets picked up by a I/O thread when all the
requests in front of it has been processed. It does not matter if the
request gets delayed in request_queue2 for 10ms if there already is 10ms
of queued requests in front of it in request_queue. It still adds up to
the same queue latency sum, only spent in different places.

/Henrik
Received on Sat Mar 17 2001 - 06:28:22 MST