On Fri, Jan 07, 2005 at 01:20:42PM -0500, Brian Cuttler wrote:
> samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch 
> 64+0 records in
> 1+0 records out
> 
> "bs" block size, "obs" outpub BS, (there is an IBS also, which I
> am afraid of developing should this not resolve soon)

Yup, this makes sense.  Since you specified "obs", the input
block size remained at the default of 512 bytes.  "dd" read
enough of those (64) to make a 32-KB output block and then wrote
the latter.  If the file had been longer, it would have repeated
the process -- 64 512-byte reads followed by 1 32-KB write --
until done.  It can also convert the other way, from a large ibs
to a smaller obs.

For a disk file, the block size doesn't matter much; things speed
up if you use a larger one, but you get the same result except
for dd's stats at the end.  For a tape, block size can be a lot
more important.

With a traditional tape drive that uses variable-length blocks,
each write() system call produces exactly one physical tape
block, whose length is simply the length specified to write().
Correspondingly, each read() call reads exactly one physical tape
block; the length specified to read() must be at least as large
as the block currently under the heads, or something will go
wrong (on Solaris SCSI tapes, as I mentioned before, the read
will fail with ENOMEM; I don't know whether other systems behave
differently, but one thing that almost certainly will *not*
happen is that you get the first chunk of the physical block on
this read(), and the next chunk on the next read().  One physical
block for each read() call is the rule.

This is why "dd" has separate "ibs" and "obs" arguments in the
first place -- to let you reblock a tape, i.e. copy it to another
tape while changing the block size, without making an
intermediate copy on disk.  When copying from one disk file to
another, or between tape and disk, specifying different input and
output block sizes doesn't really accomplish anything.

I don't know how tape drives with fixed-length blocks (or
configured for them, as in your case) work.  Perhaps the drive
does the necessary block-length conversion itself, using its
internal RAM buffer.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
The animal that coils in a circle is the serpent; that's why so
many cults and myths of the serpent exist, because it's hard to
represent the return of the sun by the coiling of a hippopotamus.
        - Umberto Eco, "Foucault's Pendulum"