Hi, 05.11.2007 15:40,, Michael Galloway wrote:: > i'm going to just add this bit of data into the mix. dd onto and > off the tape device: > > # dd if=/dev/zero of=/dev/nst0 bs=65536 count=100000 > 100000+0 records in > 100000+0 records out > 6553600000 bytes (6.6 GB) copied, 61.687 seconds, 106 MB/s
Is this with hardware compression turned on? If it is, it's not an interesting result, I fear - the nulls will be compressed to nearly nothing. And the effective throughput quite low :-) > # mt -f /dev/nst0 rewind > # dd of=/dev/null if=/dev/nst0 bs=65536 count=100000 > 100000+0 records in > 100000+0 records out > 6553600000 bytes (6.6 GB) copied, 58.3182 seconds, 112 MB/s > # mt -f /dev/nst0 rewind > # dd if=/dev/zero of=/dev/nst0 bs=65536 count=300000 > 300000+0 records in > 300000+0 records out > 19660800000 bytes (20 GB) copied, 181.502 seconds, 108 MB/s > # mt -f /dev/nst0 rewind > # dd of=/dev/null if=/dev/nst0 bs=65536 count=300000 > 300000+0 records in > 300000+0 records out > 19660800000 bytes (20 GB) copied, 215.185 seconds, 91.4 MB/s > > so at least it would seem that the drivers/adapter can move data > at an acceptable rate. Looks like it, yes. > i've done an strace of btape test and it hangs when the scsi bus > hangs, and would be glad to make the file available to to anyone > that thinks they can help. Kernel module developers might be better for this stuff... SCSI bus hangs are, in my experience, most of the time caused by hardware issues or driver problems, not directly by the application software. I'd even say that, if the application software can, by writing to the SCSI bus, hang that, it's a driver bug. Arno > -- michael > > > > On Fri, Nov 02, 2007 at 09:15:08PM +0100, Arno Lehmann wrote: >> Hi, >> >> 02.11.2007 17:55,, Michael Galloway wrote:: >>> ok, i'd like to revisit this issue. i changed scsi cards and i still >>> get scsi crashes from btape test command. new card is adaptec 29320: >> Bad. >> >>> 03:06.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10) >>> >>> i spent the morning tar onto and off the LTO-4 drive: >>> >>> [5:0:15:0] tape IBM ULTRIUM-TD4 7950 /dev/st0 >>> >>> with no issues. then i erased the tape and started with btape again: >>> >>> ./btape -c bacula-sd.conf /dev/nst0 >>> Tape block granularity is 1024 bytes. >>> btape: butil.c:285 Using device: "/dev/nst0" for writing. >>> btape: btape.c:368 open device "LTO4" (/dev/nst0): OK >>> *test >>> >>> === Write, rewind, and re-read test === >>> >>> I'm going to write 1000 records and an EOF >>> then write 1000 records and an EOF, then rewind, >>> and re-read the data to verify that it is correct. >>> >>> This is an *essential* feature ... >>> >>> btape: btape.c:827 Wrote 1000 blocks of 64412 bytes. >>> btape: btape.c:501 Wrote 1 EOF to "LTO4" (/dev/nst0) >>> btape: btape.c:843 Wrote 1000 blocks of 64412 bytes. >>> btape: btape.c:501 Wrote 1 EOF to "LTO4" (/dev/nst0) >>> btape: btape.c:852 Rewind OK. >>> 1000 blocks re-read correctly. >>> >>> hangs there with this in the dmesg log: >>> >>> dmesg >> ...snipped. I can't understand that stuff easily. >> ... >>> so, in the end i cannot make a successful btape test run with this LTO-4 >>> drive >>> with two different scsi cards. i guess my question is, is this a bacula >>> btape >>> issue or an LTO or spectralogic scsi issue? >> I'm really not sure... I know that btape works correctly; at least it >> did so everytime I used it. >> >> LTO tapes, too, can be used without problems by Bacula, and btape >> testing them works for me and many others, too. >> >> Finally, I'm quite sure that Bacula is run on Spektralogic hardware >> somewhere out there. >> >> Currently, I can only recommend to ensure you've got the latest >> firmware for HBA and tape device, a proven driver and kernel on your >> system, and run a current version of btape. >> >> If the problem persists (which I assume) you should file a bug report >> at bugs.bacula.org and perhaps also contact the developers of the SCSI >> driver you're running. >> >> Apart from that I can only wish good luck... >> >> Arno >> >> -- >> Arno Lehmann >> IT-Service Lehmann >> www.its-lehmann.de >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
