Hi, 10.09.2007 16:21,, Chris Howells wrote:: > Hi, > > I am currently struggling to get any kind of reasonable performance out > of Bacula on my LTO 4 tape size. I have done a considerable of testing > and benchmarking, and my hunch is that bacula's block size of 64512 > bytes is causing the performance problems. > > To test the drive, I used tar, with various block sizes. > > "Blocking size" in tar-speak refers to n * 512 bytes, so a blocking size > of 2048 actually means a 1048576 byte block. > > My results show: > > Blocking size Time MB/s > 126 105 20.78 > 250 81 26.94 > 1000 54 40.41 > 1500 43 50.75 > 2048 34 64.19 > > Plotting Blocking size against MB/s shows a direct linear relationship > between blocking size and time (and therefore MB/s). > > A blocking size of 126 corresponds to a block of 64512 bytes, as used by > bacula. Strangely enough (or not :) this is *nearly exactly* the maximum > performance that I have ever seen bacula write to the drive. > > I have tried bacula using the Fifo "virtual" backup device and I can > data coming in at speeds far, far in excess of the 20MB/s. In fact I > have had it coming in from two servers at 800Mbit/sec over a GigE > network. I am therefore confident that it is not the bacula catalogue > causing performance issues. > > I am also getting very little compression with bacula - presumably this > is because the tape drive can't compress 64512 blocks very well, and > needs to operate on larger chunks of data. > > Is there any way to safely increase the size from 64512 blocks to see if > that helps matters? I understand that running bacula in fixed-block > sized mode is not good. Why is 64512 bytes used anyway? It is not a > power of 2.
IIRC, that's exactly the point - there seem to be drives and drivers out there which don't work too well with 64k block sizes. Anyway, your above findings are similar to experience, for example, published in the German magazine ix. I'll try if I find that article and see if I can post some detailed information. Also important, I don't see a reason why you could not use larger block sizes - some few MB might be reasonable. You would do well do clearly document this in your emergency manual, though. Also, try not to have tapes written with different block size settings in your production pools - you will probably run into trouble if you try to restore from them in a year or so. I'd suggest to do some tests with Bacula, and after you found your best settings, clearly mark all tapes with their respective block sizes. Arno > Thanks for any help. > > ------------------------------------------------------------------------- > 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-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
