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