Red Hat Bugzilla – Bug 38404
IDE tape not finding EOF mark
Last modified: 2005-10-31 17:00:50 EST
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.
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.
email@example.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.
In addition, the comments from Bug 36628 work perfectly as a general fix for the
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]
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.