Bug 38404 - IDE tape not finding EOF mark
IDE tape not finding EOF mark
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Pete Zaitcev
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-04-30 12:29 EDT by Tesfamariam Michael
Modified: 2005-10-31 17:00 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-10 18:12:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Various kernel messages whilst using cpio (2.83 KB, text/plain)
2001-07-18 06:29 EDT, Andy Johnson
no flags Details
The fix (2.26 KB, patch)
2001-07-18 14:23 EDT, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Tesfamariam Michael 2001-04-30 12:29:54 EDT
When using RH7.1 on a sytem that has a Seagate TR5 IDE tape drive, 10/20GB 
capacity with firmware 8A51, dumping data using 
   "tar -cvf /dev/ht0 /usr/share/doc" 
and restoring it using 
   "tar -xvf /dev/ht0"
restores all the data but tar complains of not finding EOF mark with this 
   "tar: Unexpected EOF in archive"
   "tar: Unexpected EOF in archive"
   "tar: Error is not recoverable: exiting now"
This is most likely due to the ide-tape driver.
Comment 1 Tesfamariam Michael 2001-04-30 12:38:58 EDT
I will send a trace of this later.
Comment 2 Bernhard Rosenkraenzer 2001-04-30 12:46:10 EDT
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.
Comment 3 Joel Flaker 2001-06-19 11:33:18 EDT
This is a related problem bug# 36628. Please see comments and merge problems.
Comment 4 Andy Johnson 2001-07-18 06:29:03 EDT
Created attachment 23947 [details]
Various kernel messages whilst using cpio
Comment 5 Andy Johnson 2001-07-18 06:30:13 EDT
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.
Comment 6 Andy Johnson 2001-07-18 06:38:36 EDT
tesfamariam_michael@dell.com - 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.

Comment 7 Andy Johnson 2001-07-18 07:52:56 EDT
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.
Comment 8 Pete Zaitcev 2001-07-18 14:23:46 EDT
Created attachment 24027 [details]
The fix
Comment 9 Pete Zaitcev 2001-07-18 14:27:25 EDT
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.
Comment 10 Tesfamariam Michael 2001-08-23 16:40:19 EDT
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.
Comment 11 Pete Zaitcev 2001-08-23 16:48:05 EDT
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.
Comment 12 John A. Hull 2001-10-04 17:28:18 EDT
Reopening bug. Was formerly a duplicate of 36628, but that one is for a 
different TBU manufacturer. This one is for Seagate.
Comment 13 Pete Zaitcev 2001-10-04 18:52:52 EDT
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.
Comment 14 Tesfamariam Michael 2001-10-04 19:47:27 EDT
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
Comment 15 Tesfamariam Michael 2001-10-04 19:48:28 EDT
It happens with all RH releases starting from RH7.1.
Comment 16 Pete Zaitcev 2001-10-10 15:47:49 EDT
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.
Comment 17 John A. Hull 2001-10-10 18:12:07 EDT
Sorry for not replying; Tesfamariam's comments explain the issue.
Comment 18 Pete Zaitcev 2001-10-10 18:26:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.