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. 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
