On Thursday 20 September 2007 14:55, Chris Howells wrote: > Hi, > > Kern Sibbald wrote: > > For Chris: well if you consider 22MB/sec vs 25MB/sec *far* slower you > > have a different concept of the world than I do. Yes, one might expect > > Bacula to be > > Sorry for not being very clear. It is "far" slower because we are > replacing two LTO-2 tape drives with a single LTO-4. We could write to > both of these LTO 2 at a combined rate of ~50MB/sec, but since I cannot > get more than ~22MB/sec out of bacula writing to LTO-4 in its default > configuration, it will be "far" slower overall :)
Well, that is a bit of a pain. > > > able to write to an LTO-4 faster than an LTO-2, but it many cases the > > tape write time is not the big bottleneck in a Bacula backup. > > Indeed, and that is why I spent a very long time benchmarking various > parts of bacula. I have seen that bacula will happily back up this data > to the Fifo /dev/null device at about 100MB/sec. > > The moment I start using the tape again the figure drops to ~22MB/sec. You might try Bacula data spooling to a very fast RAID. That should allow Bacula to feed the SCSI controller faster. > > Changing the block size in bacula is the only way I have seen that will > increase performance. Perhaps. I personally wouldn't have a problem increasing the size to 256K or possibly 512K on an LTO-4, but I'd still hesitate. > > I have considered upgraded the kernel from 2.6.15 to 2.6.22. > > > You might get much more satisfactory results if you start with a > > different premise from "Bacula *will not* write any faster to ... than > > ...". An > > That's a bit unfair IMO :) I wasn't aware of all your tests, and I wasn't meaning to be critical or unfair. However, I agree with you :-) > I *love* bacula am I am a very happy bacula > user at home. > > That however is my conclusion, based on empirical evidence, after > spending several weeks benchmarking bacula. Unfortunately I cannot > immediately dump my results to the list for confidentiality reasons and > NDAs (yes, it sucks...). > I will however do my best to post further benchmarks to the list. OK, they will be interesting to see. > > > appropriate one might be "what are the things I can do to speed up the > > backups?" or "what really are the bottlenecks", > > That is *exactly* what I posted here! :) :-) > > > or "why can someone else > > write at 72.28 M bytes/second, but my system does not?". > > Indeed, though it's not a particularly fair comparison: different types > of LTO drives made by different manufacturers, with a different HBA, > different connection (SAS vs SCSI), and a different kernel. > Yes granted, but it does show how complicated it is. By the way, make sure you (Ralf this is for you too) that you don't have any caching turned on in your HBA. It will have nasty consequences when Bacula reaches the end of the tape where it expects to get the logical end of tape signal synchronously. Regards, Kern ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
