> Did you try 'disklabel -w da0 auto'? Yup - it also complained.
> No, it would cause a higher I/O load. Vinum doesn't transfer entire > stripes, it transfers what you ask for. With a large stripe size, the > chances are higher that you can perform the transfer with only a > single I/O. Even if I'm using really large reads? > > > I'm seeing 4.4MB/s if I read from an individual disk, but only about > > 5.6MB/s when reading from the striped volume. > > How many concurrent processes? Remember that striping doesn't buy you > anything with a single process. You might like to try rawio > (ftp://ftp.lemis.com/pub/rawio.tar.gz) and see what that tells you. OK, I was just using good ol' dd, with dd if=/cfs/foo of=/dev/null bs=2m > > > Looking at the systat display, the 8k fs blocks do seem to be > > clustered into larger requests, so I'm not too worried about the FS > > block size. What have people observed with trying larger FS block > > sizes? > > I don't know if anybody has tried larger FS blocks than 8 kB. I once > created a file system with 256 kB blocks (just to see if it could be > done). I also tried 512 kB blocks, but newfs died of an overflow. > I'd expect that you would see a marked drop in performance, assuming > that it would work at all. > OK. The minimum data size read from these files tends to be about 10k. I'll have to try this all with a real app. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
