[ On Mon, December 11, 1995 at 09:55:24 (+1030), Ian Dall wrote: ]
> Subject: Re: Tapeboot problem SOLUTION
>
> I doubt that is the cause. I had the same problem and I traced it to
> dd and possibly the tape driver.

The problem is definitely in the tape driver.  Any QIC driver should, by
definition, fail write(2)s that are not a multiple of 512 bytes (since
this is what the device expects).  In my recollection only AIX ever got
this correct.  Some device drivers gratuitiously do the "conv=sync" for
you, and I find that far more confusing and problematic in the end.  If
you've got another the works right, I'll add it to my list!  ;-)

Dd, on the other hand, is doing exactly what you've asked it to do.
It's a very simple tool with some complex options -- you must use it
with the same care as machine language, to make an odd analogy.  The
best way to figure it out is to read and understand its source.  BTW,
the GNU dd is a bit weird and may not have exactly the traditional
semantics, but it is a lot easier to read (if you first run it through
'indent -bad -ncdb -d0 -nfc1 -i8 -l256 -sc'  ;-).

> In short, the bs=8k doesn't do much. This might be specific to the
> version of dd, but I tried both GNU dd and netbsd dd. Adding conv=sync
> doesn't help because that pads reads to 8k causing heaps of embedded
> nulls every time the read from the pipe is short (every time with a
> block size of 8k).

Using "ibs=512 obs=8k conv=sync" may help, assuming gunzip never writes
anything but 512-byte or 1024-byte chunks down the pipe (i.e. if it uses
stdio).  If you're using SunOS though it may be better to use "obs=126b".

In general using dd on a unix pipe file is asking for trouble unless you
are either prepaired for slow operation, or you can safely make several
assumptions about the sizes of reads and writes, etc.

BTW, I can never remember all the different pipe semantics on various
unixes, but I think it is usually safe to assume that the maximum atomic
write(2) allowed on a pipe is 4096 bytes.  On v7 I think it was 5120
bytes (10 blocks), but some investigation I did when writing a tape copy
and verify script for SunOS-4 some time ago suggested that 4k was the
limit there.  Yes, that's correct, according to fgrep:

	param.h:#define PIPE_BUF 4096           /* pipe buffer size */

-- 
							Greg A. Woods

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