On 8/9/2010 8:16 PM, Dan Langille wrote:
> On 8/9/2010 4:23 PM, Rory Campbell-Lange wrote:
>> On 04/08/10, Rory Campbell-Lange (rory AT campbell-lange DOT net) wrote:
>>> On 03/08/10, Dan Langille (dan AT langille DOT org) wrote:
>>>> On 8/3/2010 7:09 PM, Rory Campbell-Lange wrote:
>>>
>>>>> Yes, a batch insert is faster than a specfic insert, but the latter
>>>>> should be done at the "written-to-tape" transaction time, and could be
>>>>> done asynchronously, but in a transaction.
>>>>
>>>> So... don't use batch-insert.  Go the single insert approach.  I dare
>>>> you.  ;)
>>>
>>> Yes, I'm trying! I'm trying to do it properly by recompiling debian
>>> stable backports and I'm running into library dependancy problems.
>>
>> Done. I've recompiled with batch inserts set to off.
>>
>> I tested spooling to see how this would work although it isn't strictly
>> necessary for my situation (a single server with AoE and internal
>> storage and a locally attached tape drive). The backup started running
>> off disk at around 100MB/s and then spooling at around 100MB/s. The disk
>> copy slowed down dramatically over the weekend due to contention due to
>> some external MD5 audits and rsync processes.
>
> Well, spooling data to disk first makes sense if your network cannot
> keep up with your tape drive.  You want to avoid start/stop on the tape.
>
> Spooling attributes is different.  You may want to try that on and then
> off to see how things go.  Off is what we wanted to avoid I think.

Oh... Spooling Attributes = No is what you want to use I think.


-- 
Dan Langille - http://langille.org/

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users