On Tue, Dec 13, 2005 at 01:16:20PM +0100, Markus Wernig wrote:
> Hi all!
>
> I have a system (obsd3.8/sparc64) with 2 identical scsi drives (4
> partitions + 1 swap each). The largest partition (10G) is mirrored over
> the 2 drives as a ccd with interleave factor 16.
>
> When running iostat during an I/O stress test (writing many small files
> to the ccd in 10 parallel threads), the output shows different values
> for KB/t and t/s respectively for the physical drives and the ccd.
> Sample lines look like
>
> tty sd0 sd1 ccd0 cpu
>
> tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id
> 0 4 6.34 199 1.23 6.20 200 1.21 9.94 125 1.22 2 0 3 2 93
> 0 90 6.07 217 1.28 5.90 188 1.09 8.88 125 1.09 2 0 4 1 93
> 0 30 6.03 210 1.23 5.83 237 1.35 8.64 160 1.35 0 0 1 2 96
>
> To my understanding this shows that larger blocks are written to the ccd
> in less transfers than to the physical disks, tantamounting to the same
> absolute data amount (iostat -I shows similar figures). When trying to
> understand the relationship between the single transfer rates (~6 KB/t
> in ~200 t/s on the physical disks and ~10 KB/t in ~120 t/s on the ccd) I
> realized that my knowledge doesn't suffice.
> Does anybody know how those figures relate? Where are those block sizes
> specified?
> And 1.2M/s is rather less that what I'd have expected, is this figure
> really the disk transfer rate?
>
> Thanks for any hint.
>
> /markus
There was a lengthy thread about ccd mirroring here. Search the
archives, and check whether it's worth the risk of ccd 'eating your
data' first. (If not, go with RAID-1.)
As ccd is very much a virtual device, it's rather possible that it mucks
with the write() calls between the application and the disk. So I
wouldn't be too surprised seeing different sizes, as long as the totals
are the same - which they are (okay, not perfectly, but close enough -
it's not an exact science).
That being said, I'm not quite an expert on this kind of benchmarks, but
your interpretation seems correct. I agree that 1.2MB/s is not very fast
- but the drive will be seeking a lot, so it's possible. Could you post
more information on your hardware? I don't think I'll be able to help
you much, but someone else may.
And people really like seeing dmesgs here...
Joachim