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 (r...@campbell-lange.net) wrote: >>> On 03/08/10, Dan Langille (d...@langille.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
