Xref: utzoo comp.unix.wizards:6719 comp.sys.dec:554
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!bloom-beacon!athena.mit.edu!nessus
From: nessus@athena.mit.edu (Doug Alan)
Newsgroups: comp.unix.wizards,comp.sys.dec
Subject: Re: bug report etiquette
Message-ID: <3261@bloom-beacon.MIT.EDU>
Date: 27 Feb 88 06:03:02 GMT
References: <2323@umd5.umd.edu> <10102@ulysses.homer.nj.att.com> <2338@umd5.umd.edu> <10110@ulysses.homer.nj.att.com> <2346@umd5.umd.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: nessus@athena.mit.edu (Doug Alan)
Organization: Kate Bush and Butthole Surfers Fandom Center
Lines: 17

In article <2346@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes:

> (For that matter, I know of no one who uses cooked /dev/mt devices
> anyway.  Without a way to set the block size, and given the
> repositioning error on 9 track tapes, what good *are* block tape
> devices?  They make terrible disk drives.  Hence a bug in the block
> code is hardly juicy.)

I've used block tape devices a lot.  We have many DEC TK50 streaming
tape drives here (one came with every one of a couple hundred VS2's we
received).  The TK50 performs very very very slow and unreliably if it
doesn't get to stream.  The block device is double buffered, while the
raw device is not.  If the raw device is used with the TK50 drive, the
tape drive doesn't stream.  If the block device is used with the TK50
drive, the tape drive does stream, and is much much happier.

|>oug /\lan