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