Amanda-Users

Re: Onstream ADR50 Block Size

2003-04-11 11:08:37
Subject: Re: Onstream ADR50 Block Size
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Fri, 11 Apr 2003 09:24:12 -0400
On Fri April 11 2003 05:01, Henning P. Schmiedehausen wrote:
>rwk AT americom DOT com writes:
>>I am trying to run amanda 2.4.2 on Linux RH8.0 using an Onstream
>> ADR50 drive.
>
>I assume that you have the ADR50 SCSI drive. If you do, junk it.

And here you have the definitive answer.  Someone prior to you made 
a bad buying decision, so the accountants really should just write 
it off instead of siccing the next bright person they hire off to 
spin his wheels.  The only option would be to rewrite amanda enough 
to make amanda hold everything in the holding disk until its all 
ready to stream to the drive in one swell foop, non-stop.  For a 50 
gigger, thats obviously going to be a seperate disk, but they're 
cheap today.

How much of a re-write that might be, I'll leave to the real coders, 
I just play a troubleshooter in tv.  :)

>Sorry, but that's about the only thing that I can tell you. The
> ADR50 SCSI versions have an OnStream confirmed firmware bug that
> makes it impossible to use them with Amanda. End of Story.
>
>The problem is the pause between writing the header and the data
>blocks (or between data blocks). If this pause is longer than
> about 90-120 seconds, the drive will forget its position on the
> tape. On the next write, your backup is toast. The resulting tape
> will either give read errors which can be fixed by writing new
> data over it or will even be unreadable forever (I nuked three
> tapes by doing so).

Thats the first believeable explanation of the problem I've seen, 
thank you for posting it, and the interchange between you and the 
former OnStream folks that continues below.

>The scary thing is, that you won't notice this while writing. You
> will notice it when you read data from the tape. Like in "I do
> need that backup _now_". That's why I do run amverify after each
> backup to see if I can actually read the data just written back
> in. Got burned and learned this the hard way.
>
>OnStream confirmed this a problem in their 2.39 firmware and told
> me "we will fix this if we ever release a new firmware for the
> old ADR drives (which they never did). Until then, please use the
> supplied backup program".
>
>If you're still willing to bet your data on such a drive, you can
>configure Amanda to put all backups on the holding disk and then
> flush them to the tape. By flushing you won't get any writing
> time gaps and the backup will succeed.

I have to ask, how does one go about doing this?

>Onstream Support will tell you that "this is a problem with your
>OS". This is BS. I tested and confirmed the problems on three
>different SCSI controllers and on three different OSes (FreeBSD,
>Linux, Solaris 2.7).  Only after they couldn't point their finger
> at anyone else any longer they admitted the firmware bug.
>
>Once you get past the Support, you will find out, that OnStream
>employs quite a few helpful and competent engineers. However, they
>either consider their SCSI user base dead or simply can't fix this
> bug because they don't have access to the firmware code any
> longer (OnStream went bankrupt and the current, netherlands based
> Onstream B.V. is another company that the OnStream that
> engineered the original ADR50 SCSI tape drives).
>
>Sell your drive to someone using a Windows Backup Program where it
>works fine. Don't use it with Amanda.
>
>The ADR2 tape drives (ADR60 and beyond) are fine. This is solely a
>problem of the ADR50 SCSI drives.
>
>       Regards
>               Henning

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.