tar | ssh (tar > .tar) syntax issues
 

Background:
I am currently testing a fibre attached VTL on a RHEL server. We are having throughput performance problems with Legato Networker. The vendor is suggesting that we are not able to get enough data thru our 100MB ethernet to push the VTL to high speed. I am running various test to push data to the VTL from remote systems. In one of the test I'm trying to bypass networker and go directly to the VTL tape drive using tar from a remote system. I don't want to remote mount the tape drive, I only want to push data to it.

I am attempting to tar from a Solaris system, pipe ssh to my linux server, and tar out to the VTL. The command syntax I tried first was:

tar -cvf - /usr | ssh -l root lnx_srv (tar -cvf /dev/st1 -)

The command failed, so I tried a simpler step and it's failing too.

tar -cvf - testfile | tar -cvf testfile.tar -

The input into the tar after the pipe is not recognized (which is the error I'm receiving from the 1st command as well). After many attempts I have been unable to arrive at the correct syntax. Any assistance is greatly appreciated.

In both cases you told the second tar command to create (-c) an archive, which is not what you want to do. I think you want to extract (-x) in the first instance, and possibly compare (-d) in the second? Also, in both cases, the dash needs to immediately follow (after a space) the f parameter. And in the first instance, I think you want to be extracting to a directory instead of to a device, unless I am missing something.

Thanks for the response.

If I want to move files from my Solaris box across the net and put them on the tape drive on the Linux box, wouldn't I "create" a tarball on the Solaris box, pipe it via SSH to the linux box, and "create" the write of the tarball to the tape?

If I did the operation in incremental steps I'd:
1) On Solaris box; tar cvf tarball.tar /tarred_up_directory
2) SCP the tarball.tar file to the Linux box
3) tar cvf /dev/st1 tarball.tar

or I could:
1) tar cvf - /tarred_up_director | ssh -l root Linux_Server 'cd /tmp ; tar xf -'
2) tar cvf /dev/st1 /tmp/tarred_up_directory

In both cases I'd get the files from Solaris to the Linux tape device and I'd use the "create" operation. However, the purpose of the test is to observe net transfer speed and write speed to the tape, preferably in one operation like a backup program such as Networker does.

If I don't use a command string structured something like:

tar -cf - /directory | ssh -l root Linux_Server 'tar cf /dev/st1 -'

how else would I structure it?

Thanks for your assistance.

I apologize. I haven't use Solaris and I haven't tarred onto a tape drive. I have piped between two Linux boxes using something like

.

TMK, the linux tar command when used with the -c option can accept only real files and directories as sources. If you try something like

tar -cf <file or device> -

it will interpret the dash as a filename rather than using stdin. (I have tried this with a filename; I don't have a tape drive to try it with.)

Please correct me if I am wrong, but in your sequence

wouldn't you be creating a tarball of a tarball? I.e. an archive consisting of one file which itself was an archive? If you were to try that through piping, even if you could convince tar to accept it, it would not know what to call the file it archived. Again, I have tried this when creating a file, but not with tape.

I don't know if this will work (or even if it will create a disaster), but the only thing I can think of is using dd to write the already created archive to tape:

Other than that I don't know what to suggest. I am sorry I don't have any better suggestions and I apologize for not having digested your original post better.

EDIT: corrected format of dd command

I agree with blackhole. It looks like you are trying to create a tarball of a tarball. Try the dd command that he listed or this should work too.

tar -cvf - /usr | ssh root@lnx_srv "cat > /dev/st1"

First, no apology necessary. You and Albinojap are the only two people who've attempted to help me. I sincerely appreciate it.

Second, changing the remote tar to a dd command does indeed do what I want to do. Thanks!
The command I used was:

tar cf - ./testfile | ssh - root LinuxServer 'dd of=/dev/st1'

On the Linux server I was able to extract the file from tape using:

dd if=/dev/st1 of=testfile.tar

I was also able to untar testfile.tar to retrieve my original testfile.

Your observation about creating a tarball with single file which was also a tarball is correct. There's no problem doing that other than tar needing to know the name. That one fact had escaped me. The error message I was getting included a comment about "file not existing" which should have tipped me off. This just goes to show that a 2nd pair of eyes on a problem is good thing. :)

Interesting that dd doesn't care about the name. It just wrote the data to tape. When I attempted to extract the data from tape using:

dd if=/dev/st1

dd just scrolled the file contents on screen. I had to give it a name using:

dd if=/dev/st1 of=testfile.tar

in order to capture the output data in the correct form. Without knowing the data was a tarball I'd have been in trouble.

This is not something that I'll be attempting to use on a regular basis. But it does provide a way to transfer data across the network and write to tape as I was attempting to do. Now I can go forward with my speed tests.

Thanks again!

Thats the beauty of dd. It is very low level. (Not that I am a guru with it or anything, or understand all the wonderful low level things it can do.) By default it reads stdin and writes stdout (as you discovered). The parameters if= and of= alter this behavior. The reason tar requires a name is because it is creating another archive and not just copying the existing archive to tape.

Never having worked with tape, I was wondering whether tar could directly extract from the tape that dd created (w/o the intermediate file). If you decide to try this I would be interested in the results.

I think the magic bytes at the beginning would tell you what it is.

I am glad everything worked out.