[Coreutils-users] From OCFS to tape via tar (and back again)

[Sheridan, Matt]

We're using RMAN to back up our 9.2 RAC database to an OCFS v1 volume.
We have an existing shell script that we use for copying files from disk
to tape via tar, one file at a time. (Don't ask why. It's a legacy
script. Long story.) We're tweaking this script to use --o_direct when
tarring the file to tape and that seems to be working fine:
 
# tape device is /dev/nst0
$ tar --o_direct -cvf /dev/nst0 /ocfs/RMAN_test_file 
./RMAN_test_file
 
But, to pull that same file back off tape and save it to the original
OCFS location, it seems that we cannot use --o_direct:
 
# skipping commands to reset the tape pointer to the proper location
$ tar --o_direct -xvf /dev/nst0
tar: /dev/nst0: Cannot open: Bad file descriptor
tar: Error is not recoverable: exiting now
 
But, without --o_direct, it works fine:
 
# skipping commands to reset the tape pointer to the proper location
$ tar -xvf /dev/nst0
./RMAN_test_file
 
We're assuming that using the above method (--o_direct when reading from
OCFS and writing to tape, no --o_direct when reading from tape and
writing to OCFS) provides us with a proper, working file that RMAN could
use for restores. 
 
Is this assumption correct? Or, is there some issue that may bite us
later? Like something related to direct I/O, stale cache buffers,
incorrect byte-alignment, sunspots, whatever.
 
P.S. Our RMAN backups are happening purely on one node of the cluster,
though the OCFS volume we're writing to will be mounted by the other
nodes. We may decide at some point in the future to try backing up from
multiple nodes simultaneously, but for now we're keeping it simple.
Would backing up from multiple nodes simultaneously change the answer to
the above question?
 
For the record, we're using the following:

*	Red Hat Enterprise Linux Advanced Server 3.0 Taroon Update 2
(kernel 2.4.21-15.ELsmp)
	
*	Oracle Enterprise Edition 9.2.0.5
*	ocfs-2.4.21-EL-smp-1.0.13-1
*	ocfs-support-1.1.2-1
*	ocfs-tools-1.1.2-1
*	coreutils-4.5.3-35
*	tar-1.13.25-16

Thanks in advance,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/coreutils-users/attachments/20040903/0a15ba9a/attachment.html