Oliver Fromme wrote:
Guido van Rooij wrote:
> Anyway, I created a gm device and a partition. Now the read performance
> is not what I'd expect.
> I have the partition on two SATA devices on different controlers.
> I get around 60MB/s for each disk. I can get that speed from both disks
> simultaneously.
> Now when I dd from the gm device, I don't get any speed higher than that.
That's expected.
> I tried with -b split -s <various sizes>, -b round-robin, -b load.
> (dd-ing as done with a bs of 1m; I see the transaction size is 128Kb,
> unless the split method is used, in which case the transaction size
> gies down. When round-robin is used, the transaction size is 128Kb/s,
> but the number of transaction per second goes down.).
>
> I cannot explain why I should not get a higher read speed. Anyone?
dd is a sequential, single-threaded operation, so it will
only use one disk at a time. It's not really suitable as
a benchmark for real-world things.
In the real world [TM] you have multiple processes that
access the file system at random. Here you will benefit
from the mirror, because accesses will be distributed
among the disks.
I'm still not really convinced that this should be the case....
That the real world can use the inherent parallelism is more than
obvious. Unstructured diskaccess (aka seeks) counteract this in that
same real world.
The dd process is able to read the data way much faster from the
filesystem. So if there is/was any way of forking/multiplexing the data
in the kernel buffers to both disks in parallel then you should see more
than the speed of 1 disk. This is of course also dependent on the
amount of prefetching that is done.
Now on a raw disk I would not expect that to happen, other than the
cache on the disk. On a filesystem I would expect the OS to take care of
this possibility. And perhaps I would not expect an full doubling of the
performance, since that is the theoretical max. But no gain at all is
sort of disapointing.
But like you say, this is rather academic since this type of access is
very synthetic.
--WjW
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
