Re: Amanda 2.4.2 and Onstream ADR 50 Tape?
On Thu, 2002-01-03 at 13:07, Moritz Both wrote: Hi, actually yes. I have. I did restore some backups a while ago, but it _could_ be that the Tape drive was connected to a Sym53c875. I experience exactly the same problem that you describe at the moment (on an Adaptec UW controller). I currently have a brand new advance exchange unit directly from OnStream (while my local dealer was a complete failure in getting any support, the people from the OnStream hotline are very nice and competent and _really_ helpful. For their support, I can really recommend Onstream). This brand new tape drive shows exactly the same symptoms. So I do consider this either a systematic failure in our (quite similar) HW setup (I use RH6.2+ with 2.2 kernel) or a real issue with the drive firmware which would be very sad. I'm right now in the process of swapping SCSI controllers; I will keep you informed. Regards Henning Henning, have you ever been able to actually *restore* files from amanda tapes using this device? Which is the firmware verison it has? See also my email on the list from half an hour ago. Greetings, Moritz -- 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
Re: Amanda 2.4.2 and Onstream ADR 50 Tape?
Henning, have you ever been able to actually *restore* files from amanda tapes using this device? Which is the firmware verison it has? See also my email on the list from half an hour ago. Greetings, Moritz
Re: Amanda 2.4.2 and Onstream ADR 50 Tape?
On Fri, 2002-01-04 at 00:35, I wrote: 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. :-) Hi, here are my results. Unfortunately, they're not too good: amverify adr Fri Jan 4 05:41:07 MET 2002 Loading current slot... Using device /dev/nst0 Volume adr000, Date 20020104 Checked host1._mnt_disk1.20020104.0 Checked host2.__samba_disk.20020104.0 Checked host3._mnt_disk0.20020104.0 Checked host4._mnt_disk1.20020104.0 Checked host3._mnt_disk1.20020104.0 Checked host4._mnt_disk0.20020104.0 Checked host5._boot.20020104.0 ** Error detected () amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: reached end of information ** No header 0+0 in 0+0 out I took from the amdump logfile some times for the inter-file gaps. The number in front of the FILE-WRITE is the time (from the amanda log) of the end of the write (taper return) and the start of the next dump. FILE-WRITE 02-8 DONE 02-8 adr000 1 0 FILE-WRITE 02-00019 DONE 02-00019 adr000 2 0 FILE-WRITE 02-00021 DONE 02-00021 adr000 3 0 FILE-WRITE 02-00023 DONE 02-00023 adr000 4 0 FILE-WRITE 02-00024 DONE 02-00024 adr000 5 0 FILE-WRITE 02-00025 DONE 02-00025 adr000 6 0 FILE-WRITE 02-00026 DONE 02-00026 adr000 7 In this file, the first errors occur. As you see, all dump come directly from the dumping disk which has enough files to keep the tape going. No 120 second gap anywhere. There is however, such a gap (even a really huge gap of something like 90 minutes, because one of the machines to back up wasn't online and I run with a timeout of 90 minutes for the estimates) between writing the new amanda tape label and the first dump. But verifying the first few backups on this tape is ok. An interesting datapoint may be, that _all_ of the first six backups, the disks are basically empty: DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s - -- host1 /mnt/disk1 0 64 64 100.0 0:00 0.0 0:36 1.8 host2 samba/disk 0 10 64 --0:07 1.4 0:09 7.1 host3 /mnt/disk0 0 64 64 100.0 0:00 0.0 0:09 7.2 host4 /mnt/disk1 0 64 64 100.0 0:00 0.0 0:09 7.1 host3 /mnt/disk1 0 64 64 100.0 0:00 0.0 0:09 7.0 host4 /mnt/disk0 0 64 64 100.0 0:00 0.0 0:09 7.1 (32K of Header and 32K of data, which is simply an emtpy tar block) Still, everything points at a firmware bug. I will try to hack the amanda software tonight so that the tape label is not written when the estimates are started but when the real backups start. I don't know how complicated this will be (amanda hackers?) but I'll give it a shot. I will try to contact Onstream on this matter, too. 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
Re: Amanda 2.4.2 and Onstream ADR 50 Tape?
On Thu, 2002-01-03 at 13:07, Moritz Both wrote: Hi, actually yes. I have. I did restore some backups a while ago, but it _could_ be that the Tape drive was connected to a Sym53c875. I experience exactly the same problem that you describe at the moment (on an Adaptec UW controller). I currently have a brand new advance exchange unit directly from OnStream (while my local dealer was a complete failure in getting any support, the people from the OnStream hotline are very nice and competent and _really_ helpful. For their support, I can really recommend Onstream). This brand new tape drive shows exactly the same symptoms. So I do consider this either a systematic failure in our (quite similar) HW setup (I use RH6.2+ with 2.2 kernel) or a real issue with the drive firmware which would be very sad. I'm right now in the process of swapping SCSI controllers; I will keep you informed. Regards Henning Henning, have you ever been able to actually *restore* files from amanda tapes using this device? Which is the firmware verison it has? See also my email on the list from half an hour ago. Greetings, Moritz -- 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
Re: Amanda 2.4.2 and Onstream ADR 50 Tape?
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...
Amanda 2.4.2 and Onstream ADR 50 Tape?
Hi,
I run backups with Amanda and anq Onstream ADR 50e tape (external
version, SCSI LVD) since about a year without any visible problems.
I know about the mt -f /dev/nst0 stoptions scsi2log trick for this
drive and while I wasn't able to find any explanation what this
command actually does, I use it and my backups work fine. :-)
Now I had to recover some files and had problems. While searching the
web for help, I found the following page:
http://www.linuxtapecert.org/adr50_notes.html
It states:
--- cut ---
Changing Tape Block Size
Many SCSI tape drives provide the ability to utilize various tape
block sizes. The OnStream ADR 50 only supports fixed, 512 byte blocks
in its current firmware level. We have reports from users that
attempting to change the blocksize can cause the device to hang to the
point of requiring a power cycle of the drive to clear the state.
--- cut ---
In the amanda(1) page is stated:
--- cut ---
blocksize int
Default: -32 kbytes. How much data will be written in each tape record.
[...]
The minimum absolute blocksize value is 32 KBytes. The maximum
absolute
blocksize value is 4 MBytes.
--- cut ---
Now I'm confused. Does this mean, that my backups just worked by
chance? That Amanda should't be able to either read or write on the
tape? mt reports (after rewind):
% mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
I have no problems changing the block size by issueing
% mt -f /dev/nst0 setblk 0 (variable)
% mt -f /dev/nst0 setblk 32768
but I don't know whether this change actually happens on the driver or
only in the driver.
Setting the block size to 0 or 32768 kills every attempt to read a
tape that was written with block size = 512.
Uhm. Help. Can I issue blocksize = -512 in amanda.conf to adjust for
the tape drive? Would this help? Or is it simply not possible (see
above)?
I'm using the following tape type:
--- cut ---
define tapetype ADR50 {
comment Onstream ADR 50
length 21056 mbytes
filemark 0 kbytes
speed 1579 kps
}
--- cut ---
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
