Bug 38404
| Summary: | IDE tape not finding EOF mark | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Tesfamariam Michael <afom_m> | ||||||
| Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 7.1 | CC: | afom_m, andyj, bero, jcyr, joel, john_hull, matt_domsch | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2001-10-10 22:12:11 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Tesfamariam Michael
2001-04-30 16:29:54 UTC
I will send a trace of this later. Assigning to kernel because of the ide-tape driver suspicion. Arjan, feel free to reassign this back to tar if it's not ide-tape related, I don't have access to any tape drives to try this on. This is a related problem bug# 36628. Please see comments and merge problems. Created attachment 23947 [details]
Various kernel messages whilst using cpio
I have also obtained a similar problem with RedHat 7.1 and identical tape hardware (TR5 IDE tape, Seagate 10/20Gb drive) but using cpio as my archiving tool.i.e it's kernel related not tar related. I installed the sources for cpio and did some investigation. The problem doesn't appear to be the reading to the tape at all as the data incoming is truncated by the final block being missing. On reading the tape, all filled blocks are returned, but the final, partial block that would contain the last few bytes of archive data and an end-of-archive marker isn't there (or at least a request to read it is returning 0 bytes read - which cpio interprets as an 'end of tape' signal and duly prompts for a replacement). Rather than just assuming an error with the reading and sending the device back I went further. I thought it looked as though the driver wasn't flushing the final written block to the tape when the device is closed. My understanding of it's purpose is a little vague, but adding multiple calls to <unistd.h> sync() prior to closing the tape in the write cycle of cpio didn't make any difference. Rather than get involved in the kernel driver I stopped there and came up with a work-around that suited my particular installation. As the device is being shipped to a client later next week I'm not really in a position to investigate further until I get another one in. My work-around that seems to have made cpio rock-solid was to write multiple 'end of record' markers across several blocks of the tape so that it didn't matter if the last block was missed on the read: the first one in the list would be detected and acted upon by cpio. Maybe this would work short term for tar etc. as well. tesfamariam_michael - check the restored files from your example. I'll bet that the last one restored is actually truncated and incomplete. That's certainly the case when I use cpio. In addition, the comments from Bug 36628 work perfectly as a general fix for the end user: 1) perform a 'modprobe ide-scsi' somewhere (like in /etc/rc.d/rc.local) 2) use '/dev/st0' instead of '/dev/ht0'. 3) to make use of mt-st, 'ln -s /dev/st0 /dev/tape' So forget my own work-around, this one needs no patching of anything at all.I wish I'd read bugzilla BEFORE having a go at it myself. Created attachment 24027 [details]
The fix
I do not know if bug 36628 is a dup or not. There is a mismatch in description that cannot be accounted by the root cause of this bug. The ide-tape driver is rancid, if you can use ide-scsi please do so. This issue still exists with Fairfax Beta 3 release. The drive is DMA enabled by default. If use with DMA enabled, it causes PE500 to hang and hard reset is required. It works fine with DMA disabled. I disagree with the last comment: "*this* issue still eixts. If use with DMA enabled, it causes PE500 to hang" A hang has nothing to do with the bug. File a new one if you need a resolution of the hang. Reopening bug. Was formerly a duplicate of 36628, but that one is for a different TBU manufacturer. This one is for Seagate. John, can you reproduce the bug? If yes, then tell me again what you do to reproduce it and what kernel is used. Make sure DMA is disabled with hdparm -d0. With DMA off, the issue disappears. So that is our temporary workaround. With DMA on, restoring from the tape using "tar -xvf /dev/ht0" produces the follwing error after restoring all the files: tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now It happens with all RH releases starting from RH7.1. Got no reply from John with clarification yet. This bug never was a duplicate of 36628, so he is obviously confused. I'll close again soon if no explanation is given. As for DMA, that's something I am not sure about. Arjan says he investigated switching it off for all tapes, but it was hard to do in a way that would allow to enable it later if needed.We need to document it in release notes for 7.2 EE. Sorry for not replying; Tesfamariam's comments explain the issue. By the way, this fix was pushed upstream into Alan Cox tree, for late 2.4.9-acxx. Incorporated into Red Hat by default now, without external patch. |