Xref: utzoo comp.unix.wizards:6973 comp.sys.dec:574
Path: utzoo!mnetor!uunet!husc6!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: <3652@bloom-beacon.MIT.EDU>
Date: 11 Mar 88 01:44:50 GMT
References: <2323@umd5.umd.edu> <10102@ulysses.homer.nj.att.com> <3261@bloom-beacon.MIT.EDU> <5719@cit-vax.Caltech.Edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: nessus@athena.mit.edu (Doug Alan)
Organization: Kate Bush and Butthole Surfers Fandom Center
Lines: 48

In article <5719@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don
Speck) writes:

>> [Doug Alan:] If the block device is used with the TK50 drive, the
>> tape drive does stream, and is much much happier.

> Somebody here made a similar observation about TU80's, so he did all
> his dumps to the block device.  [...] Dump [calculated] tape
> capacity based on 10240 byte blocks, but the block device was
> writing 2048 byte blocks and it wouldn't all fit.

Yup, that will happen if you don't know what you are doing.

> [He didn't notice this until later, however, when] he needed to do a
> restore, and all his tapes gave a premature EOF.  [...]  The tape
> driver [had] returned error [when writing the tape], but because
> block-device writes are asynchronous, the completion status doesn't
> get returned to anybody, so he had no indication that writes were
> not getting done (except perhaps the long pause at end of tape).

Well, I don't know what kind of system you are using, but on our
4.3BSD systems, there is no such problem.  'Dump' receives errors such
as these even when writing to the tape asynchronously using the block
device.  I know this for a fact because this very thing happened to me
last night when I made a typo and used the block device when I had
meant to use the raw device on a TU78.  A while later, 'dump' stopped,
complaining that there was a write error 1200 feet into the tape.  The
2400 foot tape on the tape drive, however, was at the end.

There *are* also a few problems using 'restore' on the block device,
but they can also be worked around.  If 'restore' gets an error while
reading the block device, it can't recover from the error and it just
gives up.  What you have to do is use 'dd' to read the tape, telling
it not to stop on errors and to pad any incomplete blocks.  The output
from 'dd', you pipe into 'restore'.

> The block device is for mounting filesystems.  Read only.  Which you'd
> probably only want to do if your tape drive is actually a WORM.  Didn't
> work correctly in 4.2bsd, though.

So you're saying that instead of using the block device to do dumps on
the TK50 and gotten dumps that worked, I should have used the raw
device and gotten dumps that didn't work?  (Using the raw device with
the TK50 results in an order of magnitude increase in time and several
orders of magnitude increase in error-rate.)  Please explain the logic
in that.

|>oug /\lan