On Thu, 2002-01-03 at 13:07, Moritz Both wrote: > > Henning, > > have you ever been able to actually *restore* files from amanda tapes > using this device? Which is the firmware verison it has?
Hi, [ There is a remotely Amanda specific reference much further below. But as some Amanda people seem to have an Onstream tape drive (or even an ADR50), I keep the Amanda-Users List as Cc on this mail. If you have an ADR50 and want to keep informed even if we take this discussion away from amanda-users, please write me a mail. Thanks. ] it doesn't seem to be so easy as we thought. I fetched your test program, and compiled it (I called it "adr50"): My HW: Intel Celeron 466 SMP (two processors), 512 MB RAM, One Adaptec 2940UW controller, exclusively for an external ADR50 tape (st0), one Symbios Logic 53c875 based (DawiControl 2976UW) controller exclusively for another external ADR 50 tape (st2). All disks are on a third controller. I run a RH 6.2 system + patches, Kernel 2.2.19, basically a RH vendor kernel + AA patches + IDE driver + some goodies. ;-) Both tapes are set in the BIOS to "Async/Wide" transfers as recommended in various articles about the ADR50. For the AIC I'm sure that this is also the case in the kernel, I'm not sure about the Symbios because I found a line Jan 3 19:49:00 babsi kernel: ncr53c875-1-<3,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 15) in my logs, which seem to contradict the BIOS setting. So I do primary testing with the AIC and then try to reproduce with the Symbios. # cat /proc/scsi/aic7xxx/0 | tail (scsi0:0:4:0) Device using Wide/Async transfers. Transinfo settings: current(0/0/1/0), goal(255/0/1/0), user(0/0/1/0) Total transfers 270 (105 reads and 165 writes) < 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+ Reads: 0 0 0 0 0 105 0 0 Writes: 0 0 0 0 0 165 0 0 I'm using st0 on the Adaptec 2940 UW. This is a brand new tape drive directly from OnStream which I got as an advance replacement for my own tape. I use two of my normal tapes, each has 5-10 cycles of wear on it. The tapes are kept in a climate controlled environment which is dust-free (or in other words: The tapes are as good as new. ;-) ) Before Testing: # mt -f /dev/nst0 stoptions scsi2log Test #1: Running on an erased tape # mt -f /dev/nst0 erase # ./adr50 /dev/nst0 ./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... Input/output error [ that one is ok. The tape has been erased. You can't read from an erased tape ] test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... done.test1: reading 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success => worked fine! Test #2, directly after Test #1, same tape: # ./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... [ INSERT A LONG, LONG, LONG PAUSE HERE, 10-15 Minutes ! ] test1: reading 1048576 bytes using 32768 byte blocks... Input/output error and from the kernel: Jan 3 23:19:46 babsi kernel: st0: Error with sense data: Info fld=0x40, Current st09:00: sense key Medium Error Jan 3 23:19:46 babsi kernel: Additional sense indicates Unrecovered read error Jan 3 23:19:46 babsi kernel: st0: Error with sense data: Info fld=0x40, Current st09:00: sense key Medium Error Jan 3 23:19:46 babsi kernel: Additional sense indicates Unrecovered read error ==> Did not work! Test #3, directly after Test #2, same tape # mt -f /dev/nst0 rewind # mt -f /dev/nst0 erase #./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... Input/output error test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... done.test1: reading 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success => worked. Test #4, directly after Test #3: # mt -f /dev/nst0 rewind # mt -f /dev/nst0 erase #./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... Input/output error test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... done.test1: reading 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success Test #5, right after Test #4 # ./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... [ INSERT A LONG, LONG, LONG PAUSE HERE, 10-15 Minutes ! ] done.test1: reading 1048576 bytes using 32768 byte blocks... Input/output error Kernel: Jan 3 23:45:34 babsi kernel: st0: Error with sense data: Info fld=0x40, Current st09:00: sense key Medium Error Jan 3 23:45:34 babsi kernel: Additional sense indicates Unrecovered read error Jan 3 23:45:34 babsi kernel: st0: Error with sense data: Info fld=0x40, Current st09:00: sense key Medium Error Jan 3 23:45:34 babsi kernel: Additional sense indicates Unrecovered read error Test #6, right after Test #5 # ./adr50 /dev/nst0 test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: rewind... success test1: writing 32768 bytes using 32768 byte blocks... + success test1: sleeping for 120 s...woke up. test1: write filemark... success test1: writing 1048576 bytes using 32768 byte blocks... ++++++++++++++++++++++++++++++++ success test1: write filemark... success test1: rewind... success test1: reading 32768 bytes using 32768 byte blocks... + success test1: skipping file mark... [ INSERT A LONG, LONG, LONG PAUSE HERE, 10-15 Minutes ! ] done.test1: reading 1048576 bytes using 32768 byte blocks... Input/output error Tests 7-12 same as 1-6 above but with the Symbios Logic Controller: #7: Success #8: Failure #9: Success #10: Success #11: Failure #12: Failure Ok, I can see a pattern here: The problem does not depend on the HW of the server or the SCSI controller. It is not related to any other SCSI device on the bus. Running Moritz' program on an erased tape -> works Running it on a non-erased tape -> fails But erasing the tape clears the problem (Ugh, it might be possible that I junked at least one tape for H/W errors because of this. =:-( ) While Moritz wrote, that his test program fails every time, I can safely assume that he didn't try with a freshly erased tape, because the same program (even with the missing \n after done. :-) ) works for me on erased tapes. And, of course, on a HP DAT DDS2 drive (which is also connected to the third controller mentioned above), all six tests in a row succeed. So the test program itself doesn't seem to have problems. I will verify this theory tonight with an acid test: An Amanda run (amdump/amverify) on a freshly erased (and labeled) tape _should_ succeed. I'll tell you in the morning. :-) Unfortunately, this really points to a firmware error in the drive =%-( (Ah the joy of single vendor technology). BTW: Does anyone from OnStream watch this list? If yes, could you please contact me via private mail? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20