[ On Tue, December 12, 1995 at 14:32:51 (-0500), der Mouse wrote: ]
> Subject: Re: Tapeboot problem SOLUTION
>
> Yeah, that's the traditional tape model.  QIC tapes break it rather
> badly.  I've seen the equivalent of the following with QIC tapes:
> 
> 	% dd if=/dev/zero bs=512 count=20 of=/dev/qic-tape
> 	20+0 records in
> 	20+0 records out
> 	% mt -f /dev/qic-tape rew
> 	% dd if=/dev/qic-tape of=/dev/null bs=10240
> 	1+0 records in
> 	1+0 records out

I don't see anything wrong with this, if we assume the "qic-tape" driver
is to do buffered reads....  In any case, RTFM to understand the
specifics, and if the driver author didn't document it properly, then
you're free to complain.

> The traditional model would have produced "0+20 records in".

Really?  I would think this would happen only for un-buffered drivers.

> Similarly, I've also seen the converse, writing large records and
> reading small records.  QIC tapes seem to behave as if they are streams
> of 512-byte units, rather than streams of more-or-less-arbitrary-size
> records.  (Plus tape marks, of course.)  Certainly SunOS behaves this
> way; I just tried it.
> 
> Very annoying. :-(

If you want really raw access to the QIC interface, then yes, it could
be considered annoying.  With a raw SCSI command interface, for SCSI QIC
tapes, this level of interface is indeed available.

However, QIC tapes are in fact streams of 512-byte records, and most
UNIX drivers do treat them as such, esp. for SCSI implementations.  The
exceptions lie in how the drivers treat reads and writes of blocks which
are not an even number of 512-byte records.  Some drivers return an
error, and some silently fill the block with NULs.  I prefer the former
to the latter, but I don't see any standard which would require either
behaviour to be correct.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>