SUMMARY : DD command question.

From: Jim Murff (
Date: Mon May 24 1993 - 22:42:28 CDT

Hello Managers;

        Thanks for the quick solution. I have learned plenty about "dd" now.

>I have been using "dd" to write a text file to
>the tape. I have tried various options and am not getting far. The man pages
>say one one thing but that doesn't seem to agree with what really happens
>(answerbook doesn't have any info). Typical command I try is ::
> ls -al copyright
> -rwxrwxrwx 1 murff 931 May 17 15:43 copyright*
> mt -f /dev/nrst0 rewind
> dd if=copyright of=/dev/nrst0
> dd: write: Invalid argument
> 1+1 records in
> 1+1 records out <seems okay but can't access the partial block>
>console shows --> st0: write: not modulo 512 block size
>The result is when I run extract_unbundle is only first block of the file.
>I have tried conv=block, obs=126b, bs=126b, etc. It seems to not like the "b"
>is NOT recognized despite assurances to the contrary ::
> dd if=copyright of=/dev/nrst0 obs=126b
> dd: write: Invalid argument
> 1+1 records in
> 0+1 records out <no good!! can't access partial block>
>console shows --> st0: write: not modulo 512 block size
>extract_unbundle shows -->
> The following product will be installed:
> 0+0 records in
> 0+0 records out

In a nutshell(no endorsement intended :) it was to use "conv=sync". It is
important to note ::

Michael Sullivan writes =>
  The "b" is indeed recognized. What is really happening is that dd does
  not pad output records by default; it only does so when conv=sync is
  specified. Therefore, if dd has less than obs bytes to output it will
  write a record shorter than obs bytes.

  While I'm on the subject of dd blocksizes I'll warn you about another
  undocumented dd feature that I've seen many people burned by: setting
  bs=n is not the same as setting ibs=n and obs=n. In the former case,
  if a record is input with less than bs bytes, it will be output with
  the same smaller size. This can be a problem when using dd in a
  pipeline over the network because sockets do not preserve record
  boundaries. The rule to remember here is that whenever using dd to
  read from a network connection and write to a raw device that preserves
  record boundaries (e.g. tape or raw disk) always supply an obs= option.
---------------------------- (Geordie F. Klueber) writes =>
  Try the `conv=sync' option to dd(1). The problem is that write(2) will
  only write what data is in it's buffer. If you specify `obs=126b' that
  just allocates enough memory to handle a 126b-sized buffer in PHYSICAL
  memory- it doesn't actually force dd(1) to write in that size.

  The `conv=sync' parameter tells dd(1) to pad all output records to the
  specified blocksize. So, if you've got a 513 byte buffer, and your block
  size is 512 bytes, if you use dd(1) without the `conv=sync' parameter
  dd(1) will try to write 1 block of 512 bytes and 1 block of 1 byte (regardless
  of what you set the output buffer size to with the `obs=' flag). If you
  use `conv=sync' with the same data, dd(1) will write 1 block of 512 bytes,
  then pad the next block with 511 bytes (to make it a full block of 512 bytes)
  and write that out as well.

Gary Riseborough writes =>
  When you write to a QIC tape, the driver or hardware limitations
  (I dunno which) mean that writes must be done in 512 byte blocks
  or multiples thereof.

  To do this,
  dd if=copyright of=/dev/nrst0 ibs=126b conv=sync

  should work. (Did one myself not 4 minutes ago! - ibs=512 though)
  the conv=sync pads the last block with nulls.

  This doesn't happen on exabyte - only QIC tapes. ****** KEY NOTE....

Thanks to everyone for their help.

Benoit Lefebvre <>
Mike Raffety <> (Russ Poffenberger) (Geordie F. Klueber) (Matt Goheen) (Gary Riseborough (ITO2)) (Birger A. Wathne)
Hans van Staveren <>
alida!swj@uunet.UU.NET (Stephen W. Jay) (Sten Gunterberg)
etnibsd!vsh@uunet.UU.NET (Glenn Satchell - Uniq Professional Services) (Michael Sullivan) (Per Hedeland) (Drew Montag)

-Jim Murff

Jim Murff ( Voice # (619)622-8878
IRT Corp, San Diego, CA. Corp # (619)450-4343
System Software Engineer/System Admin. Fax # (619)622-8888

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:52 CDT