tape positioning

[Megyes András]

Hi,

2 accident in one work :-)

I had 2 tape with 5 five file each.
I wanted to write a new archive, but i forgot to positioning to the last file. I started to write at the same time to the 2 tape on the same scsi bus...
Received error:
Jan 6 11:43:10 comis vmunix: scsi0: unknown/unhandled script exception 0xff15
Jan 6 11:43:48 comis vmunix: scsi0: HTH intr. on bus 0, SBCL = 0x67
Jan 6 11:43:48 comis vmunix: scsi0: SCSI Bus was reset
Jan 6 11:43:48 comis vmunix: scsi0: DIP intr, istat = 0x9, dstat = 0x81
Jan 6 11:43:48 comis vmunix: scsi0: illegal instruction - DSP = 0x10203b8, DCMD = 0xf1
Jan 6 11:43:50 comis vmunix: scsi0: can't find request for BA 0xffffffff (procSCSIErrors)

I had a scsi error....

Now, if I type

# mt -f /dev/ntape/tape5_d1 fsf 1

I receive the following error:

/dev/ntape/tape5_d1 fsf 1 failed: I/O error

# mt -f /dev/ntape/tape5_d1 rdpos l
READ POSITION long format
File number: 0 (0x0)
Block number: 99962 (0x1867A)

Q: How can I positioning after the "bad blocks" ?

Thanx a lot

[Michael Schulte zur Sur]

Hi,

can you describe a bit more, how you created this condition, what commands you used?

greetings,

Michael

[Megyes András]

I archived 5 times in the past, every time I positioned at the end of the last archive

# vdump -D /oracle/archive

yesterday I tried to archive again, but I forgot type "mt fsf 5", so i rewrite part of first file

# vdump -D /oracle/archive

but this isn't too bad, the bad thing a scsi error occured during the write, so a receive i/o error when I type "mt fsf 1" and I cant't walk after the i/o error section on the tape

[Michael Schulte zur Sur]

Hi,

do you need anything from after that error section?

Michael

[Megyes András]

yes :-)
I had two archive tape, both went wrong with the same error as I described above.
OK. I lost the first file but I need the remaining four.

[Michael Schulte zur Sur]

Hi,

am I right to assume, the error occurred during the backup? Do you know, how far into the tape the error occured? If so, the first one would be lost anyway. You may try to overwrite the damaged area by a new backup and then try to get to the other backups.

hopefully that will get you any further,

Michael

[Ralf Puchner]

If a scsi error occures, always check binary.errlog and verify if the problem is critical and is media or tapedrive dependant.
In case of no issue, open a call within your HP support center and prepare binary.errlog!

Another approach is to change the media (maybe it is bad) and to verify proper writing/reading using tapex utility.

In normal case, real backup programs doesn't use tapes with errors on it. An error is always the end of a savestream and usage (e.g. legato/veritas etc.). So it is not a good idea to use such medias after an critical error occured.

[Joris Denayer]

Hi,

FWIW, you could try the seek option with your mt command.

From the manpage of mt:
seek
Positions a tape at the specified coordinates. The output of the rdpos
command may be used as an argument to this command. You can specify the
value from the First block field when using the s option.

Joris

[Megyes András]

Hi all,

When the probleme had occured I read mt man page, so I tried

# mt -f /dev/ntape/tape5_d1 fsf 1

fsf 1 failed: I/O error

# mt -f /dev/ntape/tape5_d1 rdpos l
READ POSITION long format
File number: 0 (0x0)
Block number: 99962 (0x1867A)

I assumed that is the place where scsi error occured and I tried seek:

# mt -f /dev/ntape/tape5_d1 seek 0x2
# mt -f /dev/ntape/tape5_d1 rdpos l
READ POSITION long format
File number: 0 (0x0)
Block number: 0 (0x0)
mt seek leads me to the beginning of the tape.... ( as I assume)

So I decided to open this little discussion :-)

Today I tried again seek on the second tape:

# mt rew
# mt -f /dev/ntape/tape0_d1 fsf 1
/dev/ntape/tape0_d1 fsf 1 failed: I/O error
# mt -f /dev/ntape/tape0_d1 rdpos l
READ POSITION long format
File number: 0 (0x0)
Block number: 81431 (0x13E17)
# mt -f /dev/ntape/tape0_d1 seek 0x1
# mt -f /dev/ntape/tape0_d1 rdpos l
READ POSITION long format
Beginning of partition
File number: 0 (0x0)
Block number: 0 (0x0)
# mt -f /dev/ntape/tape0_d1 fsf 1
/dev/ntape/tape0_d1 fsf 1 failed: I/O error
# mt -f /dev/ntape/tape0_d1 rdpos l
READ POSITION long format
File number: 0 (0x0)
Block number: 81431 (0x13E17)

A new message appeared " Beginning of partition " What a hell is it ?


Because I've two tape I tried to overwrite the bad section as Michael Schulte suggested.

# mt -f /dev/ntape/tape5_d1 rew
# dd if=/dev/zero of=/dev/ntape/tape5_d1 bs=60k count=100100
100100+0 records in
100100+0 records out
# mt -f /dev/ntape/tape5_d1 fsf 1
# mt -f /dev/ntape/tape5_d1 rdpos l
READ POSITION long format
File number: 2 (0x2)
Block number: 100102 (0x18706)
# mt -f /dev/ntape/tape5_d1 fsf 1
/dev/ntape/tape5_d1 fsf 1 failed: I/O error
# mt -f /dev/ntape/tape5_d1 rdpos l
READ POSITION long format
File number: 2 (0x2)
Block number: 100102 (0x18706)

I hope I overwrite the original error section. What should I do now ?

The original first file contains 15621075424
bytes of data which was written by vdump. The tape : COMPAQ Super DLTtape(TM) I
I think absolutely error free(10 year in the industry :-)).




Happy new year

"Time is not important only data important"

[Michael Schulte zur Sur]

Hi,

# dd if=/dev/zero of=/dev/ntape/tape5_d1 bs=60k count=100100
100100+0 records in
100100+0 records out

I dont think, this will work. Since you get only zeroes and compression is on according to man tape.
DensityNumber = 0,3,4,5,6,7
tape?_d0, or any device name with the suffix: _d3, _d4, _d5, _d6, and
_d7. In this case, compression is set to Off (0x0).

DensityNumber = 1,2
tape?_d1, or tape?_d2. In this case, compression is set to On (0x1)

Use no compression, when overwriting and use the normal backup procedure to overwrite the error region.

greetings,

Michael

[Mohamed K Ahmed]

I think the problem is very simple.
Well it looks like you written over the old tape and it only has one set
I do this lots of times
Next time be sure to fsf the tape before writing new dumps to it .

Mohamed

[Megyes András]

OK. Mohamed come with me to wash up the next fast food floor :-)

I tested vdump on a clean tape, if you have a tape with the following layout:

r - record
* - tape mark

rrrrrrrrr*rrrrrrrrrrr*rrrrrrrrrr**

and you vdump on it

rrrrrrrrrrrr**rrrrrr*rrrrrrrrrrr**

you will get an i/o error if yout type "mt fsf 2"

Any other suggestion ?

[Michael Schulte zur Sur]

Hi,

have a look at mt seod. I am not quite sure what it does. It looks like it positions the tape at the end of data. Maybe you can use fsf or bsf depending on where the head is.

good luck,

Michael

[Mohamed K Ahmed]

Mr. Megyes Andras,
I don't know what is your problem regarding the message you posted " OK. Mohamed come with me to wash up the next fast food floor :-)", please explain it to me again.

[Mohamed K Ahmed]

Mr. Megyes Andras,

Now, regarding your reply to me, I understand and I mean what I replied.
What I understood from your message is that you had a tape with several records,

rrrrrrrrr*rrrrrrrrrrr*rrrrrrrrrr*rrrrrrrr

But by accident, you wrote on it without fsf to the end of the tape.
Well by this you might have overwritten at the begining of the tape and the tape now has:

nnnnnnnnnnnnnnnn*

where n is a new record
and in this case you would get an I/O error if you type "mt fsf 2"

We are here to help, we take time off our work and read the problems and reply with a resolution, sometimes because of all the work we have you miss some small solutions. If you don't like some responces that you might get, then don't assign points to it. That's why they have points in here.

Mohamed