Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Jul 1999 17:33:21 -0500
From:      "Mike Avery" <mavery@mail.otherwhen.com>
To:        Greg Lehey <grog@lemis.com>, questions@FreeBSD.ORG
Subject:   Re: Recomended tapes form HP?
Message-ID:  <199907212239.RAA08342@hostigos.otherwhen.com>
In-Reply-To: <19990721120333.T84734@freebie.lemis.com>
References:  <199907141328.IAA25886@hostigos.otherwhen.com>; from Mike Avery on Wed, Jul 14, 1999 at 08:24:41AM -0500

next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Jul 99, at 12:03, Greg Lehey wrote:
> On Wednesday, 14 July 1999 at  8:24:41 -0500, Mike Avery wrote:
> > On 14 Jul 99, at 16:05, Greg Lehey wrote:
> >> On Tuesday, 13 July 1999 at 18:00:32 -0500, Mike Avery wrote:
> >>> On 14 Jul 99, at 1:16, Iani Brankov wrote:

> >> Now they *did* agree that DDS (which you call DAT) is evil.

> > Well, there was some discussion there also.  But whether they should be
> > called DAT or DDS seems to vary from vendor to vendor.  DAT is the
> > physical form factor of the cartridge.  Archive and Seagate call their
> > drives DAT drives.  HP calls them DDSx, where X indicates the level of
> > the DDS format.  Archive and Seagate tell you which level DDS media to
> > use.  All in all.... I think picking on that point is rather fruitless.
 
> The term is DDS.  Agreed, the marketroids call it DAT, but what do you
> expect?  Internally, the Archive/Seagate docco refers to DDS.  And it may
> seem pedantic to you, but confusing terms can lead to trouble, and there's
> no necessity for it.

Actually, it doesn't seem pedantic, it seems WRONG. The media 
format is Digital Audio Tape, aka DAT.  Since then additional 
standards have been applied to the media and the tapes that handle 
them.  However, they remain DAT tapes, just as surely as your 
automobile remains an automobile even if it's a station wagon, a 
sports car, or an SUV.  It is incorrect to call a station wagon an 
SUV, and vice versa, but at a generic level, the terms "automobile" 
and "car" remain correct.  Similarly, they are DAT drives.  
 
> >> They are some of the most unreliable drives on the market.  I have yet
> >> to have one last two years, and I currently have replaced a drive with
> >> another of identical make, and I can't read my old backups.

> > Odd.  I have a 7 year old DAT (or DDS1) HP drive that's still going
> > fine.  I did have lots of troubles with HP DDS2 drives (if memory
> > serves).  After six months to a year, they needed to be overhauled. If
> > they were in warranty, HP did it for us.
 
> OK, what other computer equipment needs (expensive) overhauling every 6
> months?

Well, to reuse the automobile analogy, I had a Subaru that was a 
complete piece of junk.  It really helped me be a better bicyclist.  
Now then, would it be inappropriate for me to generalize from the 
Subaru to all cars?  It would.  You'll note that I mentioned my DDS1 
drive is still doing fine after 7 years.  And that I had some HP DDS2 
drives that croaked after 6 months.  It seems to be a model 
problem, not a tape format issue.  Also, you cut my comments about 
better results with the Seagate Scorpion 12/24 DAT.  Very fast, 
very reliable.
 
> > HP has played some games wherein they changed the compression
> > algorityms and made earlier tapes unreadable.  A real problem for
> > people who need to recover data from older tapes.
 
> Do you have any details?  I don't believe this is true, at least not
> for drives made in the last 5 years.

The report I got was somewhat over 5 years ago in a mailing list I 
was then on.  It related experiences from a year or so before that.  
I hope the vendors have learned their lesson on that issue.  Of 
course, that IS a problem you invite by using hardware compression.  
Even if HP remains consistent from drive generation to generation, 
that doesn't mean they are compatible with Sony, Seagate, or 
whomever.
 
> > And Sony seems to use different formatting on it's DDS2 tapes than
> > other people, so it's a BAD idea to use Sony tapes with HP drives.
> They used to.  They don't any more.

I didn't know that.  However, having been expensively burned, I've 
avoided Sony tapes ever since.
 
> > We'd be able to verify the backup and not recover data a week later.
> This sounds more like unreliability than compatibility if you ask me. If
> it had been a compatibility issue, the verify would have failed.

Yes it does, doesn't it?  However, the problem went away after we 
stopped using Sony tapes.  As a result, I have trouble blaming the 
drives in this instance.  The tapes could have been unreliable.  But, 
whatever the case, the verify came back clean, but a week later, the 
data was unrecoverable.
 
> > Worse, Sony tapes were easier to get than the other guys.
> Huh?

The report I was given (by a sales droid) was that 3M (or Scotch, or 
Imation... pick your favorite name) made most of the DDS2 tapes at 
that time.  And that they were consolidating into a new factory.  In 
preparation for this, they stopped production in the old factories 
before the new one was completed.  The factory took longer to build 
than expected.  And it took longer still to get the new one making 
decent quality product.  So the stock was depleted.  As a result, 3M 
DDS2 tapes were unavailable, as were tapes from most of the third 
party vendors - since they were buying from 3M.  Sony had their 
own factory, and their tapes were widely available.  We had to pay 
extra to get tapes that weren't Sony tapes.  The hard part was 
convincing the purchasing department that it mattered.  And that it 
mattered enough to pay the difference.  (I am grateful that wasn't 
a government job!  I'd still be arguing with purchasing over the deal.)

> > As a side note, a number of years back Scientific American ran an
> > article on the life expectancy of backups.  Their conclusion was that
> > most backups were rendered useless by the march of technology sooner
> > than the media showed problems.  
> I read that too.  I didn't agree with it.  It suggested, for example, that
> my 10-year-old QICs would no longer be readable.  They are.

Some tapes last longer than others.  How they are stored can have a 
major effect on the matter.
 
> > How much do you have on 8" floppy disks?
> A fair amount.
> > How much of it can you restore?
 
> None.  I don't have a functional floppy drive.  But a year or so ago I
> gave a copy of Seattle Computer Systems DOS/86 version 0.3 (also known as
> QDOS, the predecessor of MS-DOS) away to a guy in Canada.  The floppy was
> about 16 years old and had been treated *very* badly.  He had trouble
> reading it, but he got most of the data off.  I'd expect much less trouble
> with the floppies I've been storing correctly.

The point I was making there was that technology moves on, and 
even though the data is still on the media, doing something with it is 
another quesiton entirely.  I suggest that if you had to mail your 
diskettes to another country to find someone with the right 
combination of hardware and software to read your disks that the 
issue is not the data retention capability of the media....
 
> > Aside from that, they put the data life expectancy of DDS tapes at
> > 18 months to 2 years (if memory serves).
 
> Another case in point.  I have data on DDS tapes that is 8 years old, and
> when I have a functional DDS drive, I can read it.

I didn't say I agreed with the number, just that I was concerned by 
it.  Again, some tapes last longer than others.
 
> > I was shocked, since we'd just converted from 8mm (which has a
> > somewhat longer life expectancy).  In the end, I called 3M.  Their
> > comment was that the report was correct, but incomplete.  If you
> > store DDS tapes lying flat, their life expectancy is short.  If you
> > stack them on edge, they are supposed to be good for 10 years.
 
> Interesting.  Did they say why?

No.  I felt the person I talked to was reading from her data base 
and that was the only answer I was likely to get from her.

> > Of course, that leaves many people with the problem that the
> > current version of the backup software may not be able to read
> > tapes from the older version.  (An area where *nix shines.... I hope.
> > Some commercial firms seem to have no qualms about changing format and
> > not making them backwards compatible.)
 
> Dennis Ritchie recently (early this year) dragged out some old 3rd
> edition tapes with the system source.  To quote:
 
>   The dates on the transcription are hard to interpret correctly; if
>   my program that interprets the image are correct, the files were
>   last touched on 22 Jan, 1973.  The difficulty of interpretation owes
>   both to possible bugs in understanding the date bytes on the tape, but
>   also to epoch uncertainty.  Earliest Unix used a 32-bit representation
>   of time measured in 60ths of one second, which implies a period of just
>   over 2 years if the number is taken as unsigned.  In consequence, during
>   1969-73, the epoch was changed several times, usually by back-dating
>   existing files on disk and tape and changing the origin.  The OS here
>   implements the present standard of a New Year 1970 epoch and a
>   resolution of 1 second, but the DECtape on which it is stored uses the
>   older interval and some older epoch.
 
> This doesn't sound like he had much trouble reading the tapes, which
> must have been 26 years old at the time.
 
Cool.  Of course, the old tape drives used on older mini and 
mainframe computers haven't changed much.  And they are setup to 
optimize the tape winding for best archival data retention.

And that echoes my point, that *nix does better than most about 
having compatible tape standards.

Mike

======================================================================
Mike Avery                            MAvery@mail.otherwhen.com
                                          (409)-842-2942 (work)
                                                  ICQ: 16241692

* Spam is for lusers who can't get business any other way *

A Randomly Selected Thought For The Day:
ROFL: Results Of Fast Living...?



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907212239.RAA08342>