On Thursday 20 September 2007 11:31, Chris Howells wrote: > Hi Kern, > > Thanks for your comments. > > Kern Sibbald wrote: > > By the way, increasing the Minimum Block Size is NOT the way to increase > > the Maximum block size. In general one should *never* set the minimum > > block size unless you have an older brain damaged drive. In increasing > > the Minimum Block Size, you virtually guarantee to waste tape for no good > > reason. The way to increase the maximum block size is to use the Maximum > > Block Size directive, which I previously thought was rather obvious ... > > oh well. > > Oops. This was not obvious to me, despite having spent rather a lot of > time studying the (excellent) documentation. and consulting my best > friend, Google. I guess though that it's slightly more obvious now that > you have pointed it out, and I have contemplated it for a while :) (and > it should not be in Google for people like me with similar predicaments > in future ;)
Well, if you can suggest some appropriate additional documentation, I'll be happy to add it :-) With things like LTO-4s which virtually no computer can drive at their full speed, it is probably well worth doing some testing and documenting what one can do. > > > Unless you have a critical problem of speed, I don't particularly > > recommend starting with block sizes other than the default. It would > > require a lot > > Unfortunately I do have a critical speed problem with bacula. I need to > back up several terabytes of date in ~5 million files. With the default > block size Bacula is *far* slower than our current Legato Networker at > backing up this data to LTO 2 tape. Bacula *will not* write any faster > to LTO 4 any faster than ~22MB/sec under any circumstances. Legato will > write to tape at ~25MB/sec, or even a lot faster if it's easily > compressible. > > I have tested Bacula using the fifo backup device to /dev/null and I > believe I have comprehensively shown that there is no other bottlenecks, > e.g. system speed or catalogue speed. I can pull in data at over > 800Mbit/sec (over a GigE network) from our backup servers. Well, I will be interested to see what you discover given Ralf's results :-) > > > I would be interested to hear the experience of users who are using > > larger block sizes. First about the throughput they get, but also about > > the number of tape read errors they have, and any problems associated > > with running multiple simultaneous jobs. > > I have so far backed up and restored data from running two multiple > simultaneous jobs using a large block size. I will be doing much more > testing while I try and get this system into production. > ------------------------------------------------------------------------- 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
