Re: RAIDframe performance vs. stripe size

[Greg Oster <oster%cs.usask.ca@localhost>]

On Fri, 11 May 2012 17:05:24 +0200
Edgar Fuß <ef%math.uni-bonn.de@localhost> wrote:

> Thanks a lot for your detailed answers.
> 
> > Yes.  Absolutely.
> Fine.
> 
> > As you can see, all of those span all 4 discs.
> Yes, that was perfectly clear to me. What I wasn't sure of was that
> the whole stack of subsystems involved would really be able to make
> use of that. Thanks for confirming it actually does.
> 
> EF> I have one process doing something largely resulting in meta-data
> EF> reads (i.e. traversing a very large directory tree). Will the
> EF> kernel only issue sequential reads or will it be able to
> EF> parallelise, e.g. reading indirect blocks?
> GO> I don't know the answer to this off the top of my head... 
> Oops, any file-system experts round here?
> 
> > The parallelism seen in A will still be there, but not the
> > parallelism in B.  
> Thanks.
> 
> One last, probably stupid, question: Why doesn't one use raw devices
> als RAIDframe components? Doesdn't all data pass through the buffer
> cache twice when using block devices?

I think you'd asked that before, but I didn't get to responding, and
no-one else did either...

The shortest answer is that back in the day when RAIDframe arrived it
was made to handle 'underlying components' just like CCD did... and
using the VOP_* interfaces meant things could be layered without
worrying about what other devices or pseudo-devices were above or below
the RAIDframe layer.  Yes, things might get (initially) cached on a
couple of different levels, but as those 'bp's get recycled it'll be
the lower copies that get recycled first and you should just end up
with only a single cached copy of popular items...

I think it's one of those things where you trade a bit of duplication
for flexibility....

Does that help?

Later...

Greg Oster