Unexplained I/O error from dd

[Raynald Boucher]

Hello all,
I'm trying to find out how much space is left on a VS80 tape after performing a full database export.

My routine looks like the following but does not work because dd returns $?=2

writes=0
mt -t /dev/rmt/2mnb rew
mt -t /dev/rmt/2mnb eod
while `dd if=<800Kfile> of=/dev/rmt/2mnb bs=8192`
do
let writes=$writes+1
done

Where can I find out what the error actually is?
Is there a better writer than dd for this kind of work?

I tested the dd statement outside of the loop and it returns:
I/O Error
102+1 records in
102+1 records out
The operation appears to work because it takes a fair amount of time for the prompt to return.

Was the operation in fact successful?
If so, how can I rewrite that loop (ie how do you detect end of tape)?

Thanks
RayB

[A. Clay Stephenson]

I would rewrite it to something close to this so that the exit status is captured:

typeset -i writes=0
typeset -i STAT=0
while [[ ${STAT} -eq 0 ]]
do
dd if=<800Kfile> of=/dev/rmt/2mnb bs=8k
STAT=${?}
if [[ ${STAT} -eq 0 ]]
then
((writes += 1))
fi
done
echo "Status = ${STAT}"

You should also make sure that your 800Kfile is, in fact, an 800KiB file so that you always get 100+0 records in. This will ensure that all the input blocks are fully read each time.

[Raynald Boucher]

Hello Clay,
I modified your script slightly and got the following:

# cat testdd
typeset -i writes=0
typeset -i STAT=0
mt -t /dev/rmt/2mnb rew
mt -t /dev/rmt/2mnb eod
while [[ ${STAT} -eq 0 ]]
do
dd if=/usr/local/etc/basedata.dmp.test.Z of=/dev/rmt/2mnb bs=8k
STAT=${?}
if [[ ${STAT} -eq 0 ]]
then
((writes += 1))
fi
done
echo "Status = ${STAT}"
echo $writes

# ./testdd
I/O error
102+1 records in
102+1 records out
Status = 2
0

I'd like to know what status 2 means.

How can I create a file that has a size of exactly 800K?

I tried a few options and it seems "conv=noerror,block,sync" works but I'm not sure exactly why.
Must be something to do with those darbed VS80 drives.

# dd if=testfile.Z of=/dev/rmt/2mnb bs=8k conv=noerror,block,sync
102+1 records in
103+0 records out
# dd if=testfile.Z of=/dev/rmt/2mnb bs=8k conv=noerror
I/O error
102+1 records in
102+1 records out
# dd if=tesfile.Z of=/dev/rmt/2mnb bs=8k conv=noerror,block
I/O error
102+1 records in
102+1 records out
# echo $?
2
# dd if=testfile.Z of=/dev/rmt/2mnb bs=8k conv=noerror,block,sync 102+1 records in
103+0 records out
# echo $?
0
# dd if=testfile.Z of=/dev/rmt/2mnb bs=8k conv=noerror,block,sync 102+1 records in
103+0 records out
# echo $?
0
#

Do you have any other ideas on why this is occurring?

RayB

[A. Clay Stephenson · Accepted solution]

By convention, UNIX programs return 0 on success and non-zero on failure. What that non-zero value means is entirely the whim of the programmer although again, by convention, the exit status is set to the value of errno of the failing system call OR the signal number that triggered the termination. Errno 2 = ENOENT (No such file or directory) so this is clearly not your problem. The real key is "I/O Error" which is almost certainly the stderr output of the perror() function and corresponds to errno 5 (EIO). This means some form of I/O error (End of Media, Bad Media, Failing Hardware, ...) was detected and that is all the OS knows. Had I written dd, if errno = 5 then I would have exited with status 5 but ...

Man errno and examine /usr/include/sys/errno.h for more details.

As to how you can create an 800KiB file (meaning 800 * 2^10 Bytes) then:

dd if=/dev/urandom ibs=256 obs=1k of=myfile.dat count=3200

This will create an 800KiB file of random data (but it does assume you are running on 11.11 and up). You really want random data when testing tape drives to better challenge the compression. You should also note that trying to determine the capacity of a tape drive with compression is difficult/pointless/questionable because the capacity is entirely data dependent. For example, suppose your input file were all NUL's (e.g. using /dev/zero as your imput file). How much would a stream of all zeroes compress? The only value that you should trust is the Native capacity; you will always be able to get that much and for that number all you have to do is read the box the tape came in.

[Raynald Boucher]

Good explanation,

Thanks for the references and the file creation tip.
I had been using a compressed export file from oracle.

I'll see what else I can do next week (assuming all those DST changes work...)

Take care

RayB

[Bill Hassell]

Definition of dd: Send and pray

Seriously, dd is far too stupid to know anything about a tape drive and will never return a useful status. Your error code is almost always errno 5 meaning I/O error. So out of the dozens of potential problems with the drive or the tape, you get one status: I/O error.

You cannot detect end-of-tape when you use dd. There is no choice but to write a real program that talks to the driver and tests every action for success and requests (and decodes) full status for any errors. That way, you can detect the end of tape and do the correct thing (whatever that is). If this is an experiment in your free time, you can play around with cleaning tapes, different brands and possibly different tape drives until it seems to work. I would never use dd for any production process. dd is just too dumb to be used for this type of application.

[Raynald Boucher]

Gents,
I found a solution / workaround!

Instead of using a dmp file as input I created a OneMegFile using

dd if= ibs=256 obs=8k of=OneMegFile count=4000

This then allows the original without errors

dd if=OneMegFile of=/dev/rmt/2mnb bs=8k

Hope it's usefull to you,
Take care
RayB

[Raynald Boucher]

I think left...
I don't have /dev/urandom on my system...
something else to look for!