Am Montag, den 21.06.2010, 11:06 +0100 schrieb Alan Brown:
> On 21/06/10 10:56, Lukas Kolbe wrote:
> >
> > For comparison, I dd'ed a volume to /dev/null while the copy job was
> > running:
> > [root@shepherd ~]# dd if=/var/bacula/dp/fs1/Vol0070 of=/dev/null bs=1M
> > 9175040000 bytes (9.2 GB) copied, 12.0225 seconds, 763 MB/s
> >
> > But dd'ing it to another file reveals a problem with the storage
> > subsystem I believe:
> >
> > [root@shepherd ~]# dd if=/var/bacula/dp/fs1/Vol0070 
> > of=/var/bacula/dp/fs2/xxx bs=1M
> > 849346560 bytes (849 MB) copied, 32.665 seconds, 26.0 MB/s
> >
> >    
> 
> Try separate raid arrays.
> 
> FWIW I have 51245s here and their performance is _much_ better than 
> that.  Only the 6 disk raid6 array gets close to that and it's primarily 
> spindle/headseek limited.

I'll see when I can test with the spool on a different array. But the
problem is not only when copying within the same array, I get the same
performance problems during the CopyToTape-Job - i.e. it's reading
20MiB/sec from the array, writing *nothing* to the array at all (see the
vmstats in my first mail) and writing only around 3MiB/sec to the tape.
So I suppose it's somehow scsi-subsystem related. And as you see, the
first figure above shows transfer speeds of 763MiB/sec, and that's what
I've come to expect from our arrays with their 24 1TiB SATA disks for
sequential access.

Kind regards,
Lukas



------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users