To: linux-tape@vger.rutgers.edu (Linux Tape Mailing List) Subject: [ANNOUNCE] ftape-4.x beta test version From: Claus-Justus Heine <claus@momo.math.rwth-aachen.de> Date: 25 May 1998 13:26:41 +0200 a) I'm just about to upload a new test version of ftape-4.x to my web page. Features: i) minor bug fixes. Waits for the FDC to assert the RQM bit when the isr() is called after an interrupt. When wait_segment() fails read/write segment don't bail out any longer, but retry. Switching between writing deleted address marks and normal data wasn't always implemented correctly ii) implemented hard write error recovery: if writing to a sector fails to often, that specific sector is marked as bad in the bad sector log, the data still cached in the dma buffers is shifted towards EOT as appropriate and the ECC information is recomputed. Nothing is for free, though. My implementation of this feature needs one temporary 29k buffer, and up to, mmh, 29 additional buffers to hold the bad sectors. 29 is worst case, i.e. when all sectors of a given segment fail to be written. iii) related to ii): I removed the compression support. I'll provide a user space utility to read old compressed volumes later. Hard write error recovery was too hard with compression. And kernel level software compression could be regarded as a bug any way ... iv) the formatting ioctl interface has changed. Minor change: everybody can send "raw" QIC-117 commands to the tape drive. I did this because I have ruined one 5Meg Ditto Max tape 'cause I had installed ftformat setuid and accidentally tried to format the Ditto Max tape ... Ftape now checks for the presence of Ditto Max or 2GB and refuses to switch to format mode if so. Gna. But more important: I removed the mmap() interface. The sector coordinates are again computed inside the kernel driver. mmap() was just too difficult with parallel port tape drives. I didn't arrive at making mmap SMP safe, therefor I dropped it. This essentially reduces the size of the driver. Was a nice experiment, though. v) ftape should be SMP safe with 2.1.* kernels. I didn't try to use it with 2.0.* and SMP as my box won't run under 2.0.* and SMP. ------- For the Ditto max: I have successfully written and read back a 2.5 GB cartridge with ftape-4.x. (ok, I killed the read process while it still had 5000 segments to go till EOT, was just too tired and the tape drive was too noisy :-) While writing to the tape the hard write error recovery was activated for two or three sectors. I have the impression that the Iomega people are just a bit too optimistic about their bad sectors. But maybe it is just the comparatively huge capacity of the cartridges. Reading back detected two ro three media defects that could be corrected by the ECC code. The data rate of the Ditto Max finally arrived at 2000Mbit while I was able to read at 4000Mbit for a short while, but without hard disk access. While writing the data rate was quickly reduced to 2000Mbit. Will check this later. Maybe this is related to my SMP MB Have fun Claus -- Claus-Justus Heine claus@momo.math.rwth-aachen.de http://www-math.math.rwth-aachen.de/~LBFM/claus PGP Public Key: http://www-math.math.rwth-aachen.de/~LBFM/claus/claus-public-key.asc Ftape - the Linux Floppy Tape Project WWW : http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape Mailing-list: linux-tape@vger.rutgers.edu