On Thu, 10 May 2012 18:59:42 +0200 Edgar Fuß <e...@math.uni-bonn.de> wrote:
> I don't know whether I'm getting this right. > > In my understanding, the benefit of a large stripe size lies in > parallelisation: Correct. > Suppose the stripe size is such that a file system > block fits on a single disc, i.e. stripe size = (file system block > size)*(number of "effective" discs). Then, if one (read) transfer > makes disc A seek to block X, there is a good chance that the next > transfer can be satisfied from disc B != A, making disc B seek to > block Y in parallel. Or will this (issuing requests to different > discs in parallel) not happen on NetBSD? Unless something issues the command to disc B to fetch block Y in parallel, it won't happen. That is, if you simply make a request for block X from disc A, there's nothing in the RAIDframe code that will have it automatically go looking to B for Y. What you're typically looking for in the parallelization is that a given IO will span all of the components. In that way, if you have n components, and the transfer would normally take t amount of time, then the total time gets reduced to just t/n (plus some overhead) because you are able to do IO to/from all components at the same time. RAIDframe will definitely do this whenever it can. Later... Greg Oster