I have had the same problem with my setup.
useing redhat 6.0, the latest ftape-(unstable)
and the external ditto max.
I "seem" to be able to write to the tape.
But on a verify, it gets slower and slower,
as it shoe shines more and more, till
finaly about an hour or so into the verify
it stops to because of i/o errors.
Dose seem to work ok for small abounts,
less then 100MB.
The only thing that I can conclude from what
I have been told is that my P75 with 64mb
is to slow to keep up. Even though I have
an exact copy of that computer with 48mb,
but useing windows 95, it works fine on that.
Although I have been told that the driver
being dos based can hog up more processer
time then the true multi tasking of linux.
I finaly just gave up and am still useing my
internal ditto 2GB. I will try to use the
ditto max again when I upgrade the linux
box in a few months.
Jim,
cor van dijk wrote:
>
> Greetings,
>
> I have been using ftape-3.04d with Iomega Ditto tapes on a Linux
> (Redhat6.0) machine for quite a while succesfully. This was with "2GB"
> tapes (whose actual length is 1 GB I believe). Recently I started using
> the "3.7 GB" tapes which iomega is selling for the same drive. No
> problem was apparent when doing backups (with "tar") with these larger
> tapes. But when I try to restore a large file (say over 20 MB) then the
> drive will begin to shoeshine forever somewhere halfway such a file, and
> I have to break the operation. This has not happened with smaller
> files, say several MB. This is not an isolated case, because I had
> several of these "3.7 GB" tapes with the same problem. The "regular"
> tapes (2 GB tapes) work just fine for any length of file that I have
> used.
> Presently I do not know where the problem is: 1. the drive; 2. cassette;
> 3. ftape. 4 tar. I have to start somewhere, and that is here.
>
> If anybody has seen this problem before or has an idea what the problem
> might be, I will be most appreciative to hear about it. I have several
> GB sitting on these "3.7 GB" cassesttes, which may be inaccessible.
> Thank you very much. Cor van Dijk.
