On Sat, Oct 27, 2007 at 03:42:03PM -0500, Johan A. van Zanten wrote:
> The larger transfer units (bs=10m) are dramtically improving your
> performance with dd.
> 
> I think the default block size (AKA "blocking factor") for tar is 20
> 512-byte blocks, so that's 10 KB transfer unit.  That's less than 1/1000th
> the unit in the dd command you are using.

There's something odd going on.  It's probably caused by softdep or something.
This system had 4 GB of RAM, so the pkgsrc tree fits in RAM.  Sometimes,
extracting the tarball takes only 13 secods or so (obviously, most of the
data is not written on disk in that time).  Sometimes, the same operation
takes almost 6 minutes.  Hmm, maybe it depends on whether syncer kicks in
during the untar operation or not.

When the RAID5 performance drops, the transfer count (per second) drops
from ~10000 to 200 or below (to about 300...400 kB/s).  When this happens,
the RAID controller appears to be busy as the single disk behind the
controller also becomes real slow (loading a shell command takes several
seconds).

>  It'd be interesting to see how "dd if=/dev/zero of=foo bs=10k count=1000" 
> performs.

It makes no difference.  Both 10k and 10m block sizes give write speed of
173...175 MB/s sustained (average over 10 gigabytes of data).

I want to create a server which can stream video and audio and is not killed
by a few gcc or cvs processes running.  At the moment, I'm not confident that
I can accomplish this.  It seems a simple untar can bring all other disk I/O
to halt.  I hope someone can see whan I'm doing wrong here?

  -jm