Cant't read DDS4 fomatted DDS2 tape

[Andreas D. Skjervold]

Hi

I have a DDS2 tape with production data written on a DDS4 drive.

I want to read this on a DDS3 drive on our development servers.

To do this I create devicefiles for the DDS4 formatting on the development servers:(I do not have access to the production system, and can't create DDS2 device files there.)

# mksf -H 0/0/1/0.3.0 -C tape -b DDS4 -n
# cpio -ict sh: /dev/rmt/c0t3d0DDS4n: Cannot find or open the file.

If I create a similar device file for the DDS2 formatting:
# mksf -H 0/0/1/0.3.0 -C tape -b DDS2 -n
# cpio -ict Out of Phase -- get help
Perhaps the "-c" option should be used
which I guess is correct as this tape has higher bit/inch ratio.

As the DDS4 error message states:
sh: /dev/rmt/c0t3d0DDS4n: Cannot find or open the file.
It seems that this devicefile / driver isn't correct, and that the tape driver can't handle the DDS4 format.

Is it possible to get the DDS4 devicefile working, or is this not compatible with the driver?
(The mksf man page states driver options including DDS2 but no DDS3 or DDS4...)

rgds
Andreas

[Eugeny Brychkov]

Andreas,
why not to try '0mn' file? Or BEST file?
Eugeny

[Leif Halvarsson_2]

Hi,
DDS4 drives is compatible with DDS2 media. Try with the default device files.

[Steven E. Protter]

This is very possible.

We read DDS-2 tapes in our DDS-3 drives all the time. When HP tried to sell us a system with DDS-4, they assured us that would work as well.

Perhaps, just for fun, copy the the tape from DDS-2 to DDS-3 in a DDS-3 drive and see what happens.

If that doesn't work, its probably the device you are choosing or a bug in the current driver.

SEP

[TwoProc]

I had actually heard that data written via DDS4 tape drives are incompatible with DDS2 and below from our HP sales rep when I inquired about getting DDS4 tape drives. He wanted to make sure that I DID NOT HAVE DDS2 read compatibility requirements before letting me go further with my inquiry. So, from what I've heard, you're asking for something that can't be done.

[Shannon Petry]

While DDS4 supports read of DDS1, DDS2, and DDS3 media, the write size is too small in most cases to go backwards.

I believe that the drive states that on purchase.

Regards,
Shannon

[Frank Slootweg]

A DDSN drive can read/write DDS1 - DDSN tapes, so the DDS3 drive can read a DDS2 tape. That the DDS2 tape was written on a DDS4 drive is irrelevant, it is still a DDS2 tape (120 meter, green label).

By the way, a default device file should work for all DDS types, because the drive handles the differences. I.e. just check with "ioscan -fn -H ..." for the device files that point to the hardware address of the drive, do a "lssf" command on these device files and use one which says "best density available" and has the right submodes ("at&t" or not and "no rewind" or not).

Anyway, working with your results sofar:

> If I create a similar device file for the DDS2 formatting:
> # mksf -H 0/0/1/0.3.0 -C tape -b DDS2 -n
> # cpio -ict > Out of Phase -- get help
>Perhaps the "-c" option should be used

This is *good*. (With this device file,) You can apparently *read* the tape. That cpio does not *understand* what it reads is another matter.

Please do the following and post the results:

Rewind the tape.
dd if=/dev/rmt/c0t3d0DDS2n of=/tmp/record1 bs=1024k count=1
ll /tmp/record1
file /tmp/record1
dd if=/dev/rmt/c0t3d0DDS2n of=/tmp/record2 bs=1024k count=1
ll /tmp/record2
file /tmp/record2

[Jeff Schussele]

Hi Andreas,

It's always been my understanding that a DDS4 can write to any DDSX tape...BUT...no *lower* DDSX drive will be able to read it.
Whereas the reverse is true - a higher DDS drive can read ANY tapes created on lower DDS drives.

So I'd say that the DDS ver of the tape is irrelevant - the fact that it was *written* by a DDS4 drive is.
I don't think a DDS3 drive will be able to read the tape.

My 2 cents,
Jeff

[Frank Slootweg]

Jeff,

Please see my response.

A DDS2 tape written by a DDS4 drive is still a DDS2 tape and is (hence) in DDS2 format.

It is similar to 1.44MB and 720KB 3.5" diskettes, i.e. it is irrelevant whether a 720KB diskette is written in a 1.44MB drive or in a 720KB drive.
[Note this is *not* true for (1.2MB and 360KB) *5.25*" floppies.]

[Jeff Schussele]

Hi Frank,

Yes, I read your post.
But I wasn't sure I agreed with it.
I thought it had to do with the track-width, centering & spacing that caused the lower format drives to have trouble with tapes written by higher format drives.
Anyway, I should get a chance here in the next day or so to test this & I'll report back.

Rgds,
Jeff

[Eugeny Brychkov]

See compatibility at http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?locale=en_US&objectID=lpg50116&locale=en_US&prodSeriesId=42883&prodTypeId=12169
Eugeny

[Frank Slootweg]

Hi Jeff,

You don't have to agree with my post, as long as you realize that it is The Truth (tm) c.q. The Facts (tm)! :-)

But all kidding aside, I would be severely disappointed if I was wrong.

Anyway, the Question Author does *not* have a tape comptibility problem, because, as I wrote, he can *read* it, but cpio does not *understand* it, so I want to know why, hence my questions. Most likely the cpio options are wrong or it is not a cpio tape or it is not rewound or ...

[Andreas D. Skjervold]

Hi Frank, sorry 'bout the delay.

Here is the output of your commands:
laser:/#mt rew
laser:/#dd if=/dev/rmt/c0t3d0DDS2n of=/tmp/record1 bs=1024k count=1
0+1 records in
0+1 records out
laser:/#ll /tmp/record1
-rw-rw-rw- 1 root sys 512 Apr 3 12:47 /tmp/record1
laser:/#file /tmp/record1
/tmp/record1: awk program text
laser:/#dd if=/dev/rmt/c0t3d0DDS2n of=/tmp/record2 bs=1024k count=1
dd read error: I/O error
0+0 records in
0+0 records out
laser:/#ll /tmp/record2
-rw-rw-rw- 1 root sys 0 Apr 3 12:49 /tmp/record2
laser:/#file /tmp/record2
/tmp/record2: empty

rgds
Andreas

[Frank Slootweg]

As I suspected, this is apparently not a cpio tape.

record1 is 512 bytes, which *could* be cpio (if it was indeed written without the "B" option or/and other blocking), but "file /tmp.record1" says it is not (should say "[ASCII] cpio archive").

Please do a "cat /tmp/record1" and a "od -bc /tmp/record1" and interpret/post the results.

Make *sure* the tape is rewound before you start.

It is not a good sign that when trying to read record 2 dd(1) says "dd read error: I/O error". This suggests that there *is* a problem with the tape or/and tape drive. However it is *not* a 'DDS2 written on DDS4 and read on DDS3' issue, because the first record *can* be read.

[Frank Slootweg]

OK, so the first tape is in ASCII (i.e. "c" option) cpio format, but with only 512 bytes/record (i.e. no "B" option or other blocking).

512 bytes/record is *way* too small for DDS. That gives constant repositioning (accelerate, read, de-accelerate, go backwards, accelerate, read, etc., etc.) which gives very bad performance and very bad *wear* of the tape and drive. The blocksize should be really 32KB or more, but at a minimum 5KB (cpio(1) "B") option or 10KB (tar(1) default).

If the tape was really written by cpio with 512 bytes/record (i.e. no "B" option or other blocking), then that is probably the cause of the problem. If you have not yet ruined your drives/tapes, then I advice to rewrite the/a tape with cpio's "B" option, or use tar(1) or pax(1) or fbackup(1M) (with blocksperrecord set to (at least) 64) or ....

[Andreas D. Skjervold]

Hi

Im beginning to belive that Jeffs statement that no tape written on DDS4 can be read by DDS1-3 is the case here.

My tapes are written with cpio -oacvB

and no matter what I do, I can't read them.

rgds
Andreas

[Frank Slootweg]

> Hi
>
> Im beginning to belive that > Jeffs statement that no tape written on DDS4 can be
> read by DDS1-3 is the case here.

As I said, you *can* read the first record (see your April 03, 2003 11:06 AM GMT posting), so it is *not* a DDS compatibility problem.

You said that it was a DDS2 *tape*, written on a DDS4 *drive*. If so, it *can* be read on a DDS3 *drive*, see the compatibility matrix at the URL Eugeny posted.

Question is: *Is* it a DDS*2* *tape*, i.e. what is the length and the color of the label?

> My tapes are written with cpio -oacvB

I don't think so. When you read it the blocksize is 512 bytes (see your April 03, 2003 11:06 AM GMT posting), so the "B" option was *not* used.

> and no matter what I do, I can't read them.

Have you *re*written a (*good*) tape, as I advised in my April 03, 2003 13:25 PM GMT posting?

[I will try to fix the (too wide) formatting of this thread.]

[Andreas D. Skjervold]

Hi Frank

OK, now I have gotten new tapes from production: DDS1 and DDS2 both written in a DDS2 drive with "cpio -oacvB"

And the error is still the same (Out of sync)

I have rewritten a tape locally with success both on a DDS2 drive and a DDS3 drive.

AND... the case also includes the fact that the tapes are written on a non HP system. Is that a problem? or is cpio cpio?

rgds
Andreas

[Andreas D. Skjervold]

By the way:
The production system is Linux on a Alphastation

[Frank Slootweg · Accepted solution]

Possible causes for "Out of Phase -- get help" (which is *not* a DDS compatibility issue):

Wrong combination of "c" and "B" options (four possibilities).
Not starting with the first tape of a multi-tape archive.
Other format than HP-UX. For example see the zillion of byte order options.

As long as you have problems, do (see my April 02, 2003 14:27 PM GMT posting):

Rewind the tape.

dd if=/dev/rmt/c0t3d0DDS2n of=/tmp/record1 bs=1024k count=1
This should *not* give any error and should say:
0+1 records in
0+1 records out

ll /tmp/record1
Note the size of the file. If you use the "B" option, then this *must* be 5120 bytes.

file /tmp/record1
This should say "ASCII cpio archive" if the "c" option was used and "cpio archive" if the "c" option was not used.

Under *no* circumstance you should get a "read error", "I/O error", etc..

If the tapes are written on a non-HP-UX system, then it is probably best to user tar(1) (for writing and reading) instead of cpio(1). cpio has (too) many options which can be different, which gives (too) many possibilities and hence (too) many possible problems.

[Andreas D. Skjervold]

Bought a DDS4 drive...

now it works..

Thanks everyone for all your help.

Andreas

[H.Merijn Brand (procura]

I'm jumping in very late, but for future occasions of this problem you might consider using the GNU version of cpio which autodetects -c and has many other fine portability options. Precompiled version available on many places amongst which my ITRC site: https://www.beepz.com/personal/merijn/ or http://www.cmve.net/~merijn/

Enjoy, have FUN! H.Merijn

[Andreas D. Skjervold]

Thanx but I'm already using it, and its great..

Have fun.

Andreas

[T G Manikandan]

You should be busy!
Missing you at the database forum Category.

Have nice time!