25 Mar 2002 04:12
Re: mt(1) doesn't report file number?
Charles Shannon Hendrix <shannon <at> widomaker.com>
2002-03-25 03:12:01 GMT
2002-03-25 03:12:01 GMT
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 <at> widomaker.com
RSS Feed