Good morning. Just to let you know: I ran into the exact same problems as Chris after upgrading to 1.38.2 and my yearly backup runs for 2 days now at ~3MB/s. Before that I had rates around ~12-14MB/s which was what I would expect.
I did the bfill tests before as well and got rates around 3MB/s as well. The box has nothing to do except for the Bacula stuff, no other load. I _THINK_ it occured after I did the defblksize thingy but couldnt verify it yet, because I need my backups to finish before. *sigh* I also executed the other option command which I didnt do before, on the old box. I'll keep you informed. Cheers, Michael On Tue, 10 Jan 2006 - 12:25am, Arno Lehmann wrote: > Hi, > > On 1/9/2006 9:49 PM, Chris Hunter wrote: >> > > Some questions: >> > > i) Can you please post your bacula-sd.conf & bacula-dir.conf settings >> > > for LTO drives (especially HP Ultrium-1 drives) plus additional st >> > > options ? >> >> >> > Even though I don't operate any LTO drives here - you should supply the >> > versions of Bacula used and OS details. Otherwise, most of what other >> > people might send will not be very useful for you. >> >> >> Thanks for your reply, >> >> I am using bacula 1.38.2 which I compiled from source. I am using Scientific >> Linux 4.2, which similar to CentOS, is built on rhel4 source binaries. > > Ok, so this looks more or less like a standard setup without any difficulties > to expect. > >> I have had partial sucess with the "btape fill command". I issued the >> follwing mt commands before starting btape: >> >> mt -f /dev/nst1 rewind >> mt -f /dev/nst1 stoptions buffer-writes async-writes read-ahead > > Hmm. buffer-writes is not usually on (with my kerel and according to the > relevant documentation (Documentation/scsi/st.txt in the source tree) it > sounds > as though it should not be necessary normally. Quite contrary, I understand, > because in variable block mode (what Bacula prefers) it can become a > performance-consuming process under the wrong circumstances. > >> mt -f /dev/nst1 defblksize 0 > > If the above is actually the reason for our problem, you might try loading the > st driver/module with options. buffer_kbs and write_threshold_kbs might be a > start, but you should read st.txt yourself - I might be totally wrong. > >> Using these commands, I can run "btape fill" without errors. It writes >> ~105GB to tape in 20hrs...that's less then 2mb/s ! I think the transfer >> rate should be closer to 15Mbyte/s. > > That would be more reasonable, indeed. > >> Note that btape thinks the rate is ~1500KB/s (ie 15MB/s). > > Erm, really? I might be confused, but I calculate 1500 times kilo to equal 1.5 > mega. But I don't think this actually matters here. > >> But the drive spends most of its time idle: > > Ok, that's more interesting. Have you checked with ps or top if the machine is > busy doing other things, or if btape is waiting for something? > >> >> > > Wrote blk_block=5000, dev_blk_num=4999 VolBytes=322,495,472 rate=1528.4 >> > > KB/s >> > > Wrote blk_block=10000, dev_blk_num=9999 VolBytes=645,055,424 >> >> rate=1532.2 >> >> > > KB/s >> > > Wrote blk_block=15000, dev_blk_num=14999 VolBytes=967,615,368 >> > > rate=1531.0 KB/s >> >> >> > I don't know the reasons, but I suspect there is definitely something >> > wrong - the data transfer is much too slow for a LTO device. 1.5 >> > MBytes/second is really too slow. LTO-1 should write with much higher >> > speeds. >> >> >> > I suspect a SCSI problem, something like faulty termination, wrong >> > cables and resulting slower transfers than possible, or a too high >> > simultaneous use of the SCSI bus, for example because you've got your >> > disks attached to it, too. >> >> >> >> The autochanger is the only device on the scsi bus. Next step will be test >> termination & lvd cables :( > > As long as you can be sure that's not a problem resulting from a heavily > loaded > system, that would be the next step... but have you checked what the OS says > about the SCSI subsystem? > > Arno > > -- I love deadlines, especially the sound they make as they go whooshing by. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
