Has anyone experienced cpio backups failing/dieing once the second tape is inserted? Clues, thoughts, profound intuition?

A bit more detail:
- cpio backup of 600GB of pdf images to tape media.
- The media fills and cpio request a second tape.
- A second tape is inserted, rewound and given a moment of ritual silence.
- Press <cr> to respond to the cpio request for media
- then the backup will quits..

The backup command:
cpio -ocC 32768 --force-local -M "Tape Change Request %d" < huge.list > /dev/nst0

The hardware:
where /dev/nst0 is an HP460 using LTO2 media

The OS:
rhel 3 update 7

The S/W:
cpio-2.5-4.RHEL3

Since you're spanning tapes should you be using the nst0 (no rewind) device? Perhaps the second tape isn't being rewound when you insert it so it is trying to write at the end of the tape rather than the beginning? (It might be unless it was a brand new tape.)

Have you tried it using st0 instead?

I am performing a "rewind -vs norewind" test now but I have some additional information. I repeated the test but to a floppy device so that the time span wasn't so painful between results. What we found was that when performing the cpio when using the " > /dev/fd0" it failed on the second floppy but when using " -F /dev/fd0" it spanned just as you would expect. Per the man page for cpio, both are acceptable. CPIO bug or my incorrect interpretation? I will post an update of my test using -F /dev/nst0 and -F /dev/st0.

Thanks all for the input. Hopefully the following will help others.
I am using RHEL3, 2.4.21-40.ELsmp, and cpio-2.5-4.RHEL3.

# Rewind device and the -F option
cpio -ocC 32768 < biglist -F /dev/st0 Works as anticipated on tape changes

# No rewind device and the -F option
cpio -ocC 32768 < biglist -F /dev/nst0 Fails after tape change. Note that the device status, after inserting new media still show EOT. I did not attempt a rewind, just responded to the prompt for new media and the cpio backup died.

# No rewind device and the > option (*1)
cpio -ocC 32768 < biglist > /dev/nst0 Fails on tape change

# Rewind device that the > option (*1)
cpio -ocC 32768 < biglist > /dev/st0 Fails on tape change

*1 The usage statement tells me that the > or -F should be legal but I am getting different results.

Usage: cpio {-o|--create} [-0acvABLV] [-C bytes] [-H format] [-M message]
[-O [[user@]host:]archive] [-F [[user@]host:]archive] [--file=[[user@]host:]archive] [--format=format] [--message=message]
[--null] [--reset-access-time] [--verbose] [--dot] [--append]
[--block-size=blocks] [--dereference] [--io-size=bytes] [--quiet]
[--force-local] [--rsh-command=command] [--help] [--version] < name-list
[> archive]

So using the rewind device worked with -F? Sort of what I expected. Some tape drives do automatic rewind on ejection of tape or insertion but it sounds as if yours doesn't.

You're correct that the > should have worked too (in fact that's the only way to do it in most UNIX flavors). I wonder if the double redirects (redirect in from biglist and redirect out to /dev/st0) in your command line somehow confused cpio?

What happens if you do:
cat biglist | cpio -ocC 32768 > /dev/st0

cpio is a little unique in that it expects use of standard redirect (<, >) characters as part of its command line. For most other programs the redirect characters change the default behavior.