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: > > [r...@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: > > > > [r...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
