New: Tapes unreadable after unload
A message that is not in the archive (sent off-list or not yet received): [email protected]
(please respond via emailed reply-to-all)
Quoted 4 lines · On Wed, 20 Dec 2006 02:31:18 -0800 [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7717
Summary: Tapes unreadable after unload
Kernel Version: tested 2.6.17 through 2.6.29 with various results
I assume that means 2.6.17 and 2.6.19 failed.
Quoted 7 lines
Status: NEW
Severity: blocking
Owner: [email protected]
Submitter: [email protected]Most recent kernel where this bug did *NOT* occur: 2.6.19
And that means that 2.6.19 did not fail.
Please clarify.
Quoted 21 lines
Distribution: Slackware/Fedora
Hardware Environment: HP 530, HP Dl380
Software Environment: tar, mtx
Problem Description: Doing a tar backup works well. Data is written and is readable. Binary restore comparison is ok. After unload/load the tape produces Input/output errors. The tape is unreadable with working kernels too. Any attempt to restore data from faulty tapes were in vain until now.Steps to reproduce:
tar cvf/dev/st0/path/to/something
mtx -f/dev/sg1unload
mtx -f/dev/sg1load X
tar tvf/dev/st0tar output:
tar:/dev/st0: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting nowAll
read()attempts fail after 42 bytes. (I can attach those 42 bytes if they are of any help).
Quoted 3 lines · Andrew Morton
Quoted 1 line
Kernel Version: tested 2.6.17 through 2.6.29 with various results
I assume that means 2.6.17 and 2.6.19 failed.
I tested it with 2.6.17 through 2.6.19 including subversions (like 2.6.17.3 and such). I found that 2.6.19 works and also found two other version in the line that work. The other about 4-5 version that I have tried, did not work. The works/not works is not consistent as I found 2.6.17.x kernel that did work and 2.6.18 that did not.
If the problem is known, I'd also like to know what the problem was as I need to recover two tapes that are inaccessible now. (LTO3 400GB tapes so there was no time to erase all data even if something near the beginning of the tape is bad).
Quoted 9 lines
Quoted 7 lines
Status: NEW
Severity: blocking
Owner: [email protected]
Submitter: [email protected]Most recent kernel where this bug did *NOT* occur: 2.6.19
And that means that 2.6.19 did not fail.
Right now I'm using 2.6.19 and it works. Haven't tried it with 2.6.19.1 yet though.
Quoted 19 lines · Andrew Morton
(please respond via emailed reply-to-all)
Quoted 4 lines · On Wed, 20 Dec 2006 02:31:18 -0800 [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7717
Summary: Tapes unreadable after unload
Kernel Version: tested 2.6.17 through 2.6.29 with various resultsI assume that means 2.6.17 and 2.6.19 failed.
Quoted 6 lines
Status: NEW
Severity: blocking
Owner: [email protected]
Submitter: [email protected]
Quoted 20 lines
Quoted 1 line
Most recent kernel where this bug did *NOT* occur: 2.6.19
And that means that 2.6.19 did not fail.
Please clarify.
Quoted 14 lines
Distribution: Slackware/Fedora
Hardware Environment: HP 530, HP Dl380
Software Environment: tar, mtx
Problem Description: Doing a tar backup works well. Data is written and is readable. Binary restore comparison is ok. After unload/load the tape produces Input/output errors. The tape is unreadable with working kernels too. Any attempt to restore data from faulty tapes were in vain until now.Steps to reproduce:
tar cvf/dev/st0/path/to/something
mtx -f/dev/sg1unload
mtx -f/dev/sg1load X
tar tvf/dev/st0
I tried this with 2.6.19 and the tape was readable. Unfortunately I don't have any older kernels around to test. I have not heard about any problem like this.
Note that the data becomes unreadable after the tape is touched by mtx through sg device, i.e, bypassing st.
Quoted 5 lines
Quoted 5 lines
tar output:
tar:/dev/st0: Cannot read: Input/output error
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now
Do you find any messages with dmesg or in system log?
Quoted 3 lines
Quoted 2 lines
All
read()attempts fail after 42 bytes. (I can attach those 42 bytes if they are of any help).
Interesting byte count :-)
Signature · 1 line
Kai