Re: native win32 aufs

----- Original Message -----
From: "Kevin Littlejohn" <darius@bofh.net.au>
To: "Henrik Nordstrom" <hno@hem.passagen.se>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, March 17, 2001 9:32 PM
Subject: Re: native win32 aufs

>
> >>> Henrik Nordstrom wrote
> > Kevin Littlejohn wrote:
> >
> > > Can we pass the actual requestor through the fs'es guts? I think
not, because
> > > we want to store fs-specific info on a requestor as we do that,
but will keep
> > > that in mind.
> >
> > I see no problem. The storeIOState strucure includes a hook for
> > filesystem specific data, and how you use this is entirely up to
you.
>
> Yup - that sentence was written from pov of the sfs work, when I
didn't quite
> have the same handle on what was going on.
>
> Have started the work to create a shared interface - am coding to the
> programmer's guide and the existing interfaces. Note here, aufs
currently has
> a horrible "single request pool across the entire system" thing going,
which
> I'll be breaking up into one request queue per cache dir. That has
some other
> ramifications - it means per-cache-dir load readings will work, but it
also
> may do bad things number-of-thread-wise - I may have to fall back to
one
> thread per fs, which makes sense to me anyway (correct me if I'm
wrong, but
> that thread will be blocking on disk io, another thread won't gain us
> anything, right?).

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.

> Oh, I need to check something, tho: The aufs request_queue2 setup, is
that a
> good thing(tm)? I've got to build a generic "request queue" library
of sorts,
> was going to try and use aufs's request_queue setup, which would mean
carrying
> 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.

>
> KevinL
>

Rob
Received on Sat Mar 17 2001 - 03:43:13 MST