Am Montag, den 21.06.2010, 11:27 -0400 schrieb John Drescher:
> On Mon, Jun 21, 2010 at 7:35 AM, Lukas Kolbe <l-lists AT einfachkaffee DOT 
> de> wrote:
> > 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
> >> >
> 
> Do you have a hardware raid controller without a BBunit and thus the
> write cache is disabled to protect corruption that could occur if the
> machine crashed or lost power?

We have a BBU and the write cache is enabled. Puzzling is that the now,
and repeatedly, the same dd during the copy job works with
350MiB/second. That dd slowness must have been a one-off. 

I skimmed the bacula-sd code (mac.c and block.c) and do see why it is
not so simple to change the way copy jobs work, though.

> John

-- 
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