Subject: Re: mt(1) doesn't report file number?
To: None <port-sparc@netbsd.org>
From: Charles Shannon Hendrix <shannon@widomaker.com>
List: port-sparc
Date: 03/24/2002 22:12:01
On Sun, Mar 24, 2002 at 11:42:19AM -0800, Matthew Jacob wrote:

> I mean, yes there are a few PRs open, but I'd be interested in a list of what
> the companies that have dumped NetBSD found lacking other than lack of tape
> position info.
> 
> Maybe these companies were naive. Tape position info is 'nice' but no serious
> backup utility depends or should depend on it.

Yes, they were naive, but that hardly matters when you are trying to use
NetBSD and they see a problem, or something they perceive as a problem.

The problem was when mt status returned nothing, they assumed something
was wrong, like maybe the driver was broken.  

The last time I had one, NetBSD-sparc failed to read, but could write
to a DEC branded DLT drive.  I cannot remember the model.  Then someone
played with mt and noticed status was broken.  The machine was going to
be used as a backup server, and Linux was put in its place because it
worked from the start.

Naive?  Yeah... but then it isn't completely unreasonable to worry when
something very common looks broken.  I worried a lot when I first noticed
mt didn't do status information, and I got a spare DAT running and did
a lot of backup/restore cycles, complete with md5 checks.

Heck, I *still* worry even though it passed the tests, but because I'm
using DAT drives, not NetBSD.

Want to make some bets on how many people actually test a restore to
see if it will work?   :)

Anyway, maybe it is a bit silly, but the change to mt will have a positive
effect, because there is one serious backup utility that does depend on
tape position: a system administrator.

-- 
UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com