Re: native win32 aufs

>>> "Robert Collins" wrote
>
> Actually it will - because the O/S may do elevator seek optimisation on
> outstanding disk io requests. So if the O/S can efficiently handle (say)
> 10 outstanding requests on a disk, then you'd want 10 threads per disk.

Ok, fair enough. Next question: How does the existing code deal with keeping
order on requests? I've been trying to determine how it stops itself from,
for example, executing write requests out-of-order - it looks to me like
there's nothing that explicitly ensures order is maintained, it's more relying
on order generally working. That's probably my blindness, but I want to
check...

(sfs explicitly makes sure each request is dealt with in order by only having
one thread per fs - At least within a given fd, it feels like with multiple
threads per fs you'd have to take a bit of care not to munge things)

> > that over to other fs'es... The idea of a fail-over request queue
> struck me
> > as somewhat odd.
>
> AFAICT It's so squid doesn't block when queueing the request. The point
> is that the main request queue gets locked via the mutex when a thread
> is removing an item from the queue. The control thread therefore needs
> to store the item somewhere.

Is it not acceptable to make the locking times as short as possible, and let
the control thread wait? I mean, a lock/change a pointer/unlock sequence should
be fast enough that it doesn't bother the control thread significantly, no?
Certainly, that time will still be shorter than the time the control thread waits
in the case of non-async ufs... ;)

KevinL
Received on Sat Mar 17 2001 - 03:55:44 MST