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
