- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- tape positioning
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-06-2004 09:49 PM
тАО01-06-2004 09:49 PM
tape positioning
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 01:31 AM
тАО01-07-2004 01:31 AM
Re: tape positioning
can you describe a bit more, how you created this condition, what commands you used?
greetings,
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 02:04 AM
тАО01-07-2004 02:04 AM
Re: tape positioning
# 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 02:07 AM
тАО01-07-2004 02:07 AM
Re: tape positioning
do you need anything from after that error section?
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 02:12 AM
тАО01-07-2004 02:12 AM
Re: tape positioning
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 02:42 AM
тАО01-07-2004 02:42 AM
Re: tape positioning
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 05:35 AM
тАО01-07-2004 05:35 AM
Re: tape positioning
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 05:55 AM
тАО01-07-2004 05:55 AM
Re: tape positioning
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 09:44 PM
тАО01-07-2004 09:44 PM
Re: tape positioning
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2004 11:05 PM
тАО01-07-2004 11:05 PM
Re: tape positioning
# 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