Hello Managers;
Thanks for the quick solution. I have learned plenty about "dd" now.
ORIGINAL QUERY ::
-----------------
>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
>
SOLUTION ::
-----------
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.
----------------------------
gfkpci@borg.cis.rit.edu (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 <Benoit.Lefebvre@eng.canadair.ca>
Mike Raffety <miker@il.us.swissbank.com>
poffen@sj.ate.slb.com (Russ Poffenberger)
gfkpci@borg.cis.rit.edu (Geordie F. Klueber)
matt@wbst845e.xerox.com (Matt Goheen)
gary@aodc.gov.au (Gary Riseborough (ITO2))
Birger.Wathne@vest.sdata.no (Birger A. Wathne)
Hans van Staveren <sater@cs.vu.nl>
alida!swj@uunet.UU.NET (Stephen W. Jay)
sten@ergon.ch (Sten Gunterberg)
etnibsd!vsh@uunet.UU.NET
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
mike@trdlnk.chi.il.us (Michael Sullivan)
per@erix.ericsson.se (Per Hedeland)
djm@blue.millipore.com (Drew Montag)
-Jim Murff
-------------------------------------------------------------------------------
Jim Murff (murff@irt.com) 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