1) Read all available documentation. Read also the files in the
  subdirectory "Notes-On-ftape-2.03b". Read "README.zftape".
  Read "RELEASE-NOTES.zftape". Read the Makefile very carefully.

  Especially read README.zftape to get an idea of how to
  handle this driver.

2) Edit the Makefile. Have a good look at the make-variable
  "FDC_OPT". It is used to specify which floppy controller 
  you are using, which interrupt, which dma-channel. There are
  "standard solutions" contained in the Makefile. If your
  drive is connected to the standard floppy controller, then
  simply make sure that "FDC_OPT" is commented out.

  You probably want to use zftape dynamical memory allocation
  strategy for the dma-buffer specifying the compile switch
  -DDYN_ALLOC. It is enabled by default. Newer kernels does 
  not provide a dma buffer for ftape; you really need this
  feature for the 1.3.** kernels. 
  
3) Type "make" to compile the driver. It should compile with
  no warnings on a linux-1.3.41 kernel and with one warning
  with a linux-1.2.13 kernel. NOTE: the Makefile containes
  a line "SHELL = /bin/bash". Comment it out if you don't
  have bash.                                                  
  Typing make runs the "Configure" script automatically. This
  script keeps track of the various kernel changes since the
  1.1.* kernels.

3a) Tape "make module" or type "insmod ftape.o" yourself
  to insert the driver into the kernel.  You need to be 
  root to do that.

4) If you are compiling zftape for the first time (I mean
  "Zet"-ftape, ordinary ftape does not suffice):
  Type "make mknod" to make the devices needed for zftape.
  The /dev/rft? and /dev/nrft? devices are the same as for the
  standard ftape, but as the driver has a builtin compression
  facility it needs additional devices. Read "README.zftape" 
  to get a (hopefully) sufficient description of what each 
  device does. 
  NOTE: you need to have installed bash to do
  that. If you don't have bash, you need to create the 
  devices yourself.  Read README.zftape for that purpose
  (and have also a look at the "mknod" target in the Makefile)

5) Test the driver. Try 
   
    mt -f /dev/zqft0 status

  This should give you a status report even if no tape
  is inside the drive. 
  VERY IMPORTANT NOTE: If you are
  using the latest greatest hackiest newest kernels, then
  you need to compile the program "mt" for that purpose,
  because there has something changed with the ioctls in
  the 1.3.40 and above kernels. DO NOT BOTHER ME WITH
  MAILS saying that mt does return with "invalid argument"
  before you haven't recompiled the "mt" program. You can get 
  it with cpio package from the gnu software archives. 
  NOTE (already noted in README.zftape):
 
  mt -f <one arbitrary zftape device> setdensity <debugging level>
  
  let you adjust the debugging output printed to the console (or
  kernel log). 0 means only severe errors are reported, 9 means
  that every information available is reported (do not use 9 if 
  you don't want to pollute your kernel log). Once you are very
  sure that the driver behaves well, you might want to recompile
  it with the -DNO_TRACE_AT_ALL flag, which suppresses every 
  debugging message and reduces the size of the driver a lot
  (really, a lot!).

NOTE: If you have installed linux-1.3.37 and up, you really should 
  edit kernel/prinkt.c. The patch from version 1.3.36 to 1.3.37 
  annoyingly sets the minimum console log level to 6. That means that
  your kernel log daemon is unable to suppress the debugging messages
  of zftape, normal ftape and all the other drivers. Search for the
  statement

  #define MINIMUM_CONSOLE_LOGLEVEL 6

  and change it to a value less than 6. If you use klogd or another
  log daemon which let's you specify how much noise you want at the 
  console, you can savely set it to 1

5a) Try to do a sample backup.
  Before you can do that with the zftape driver, you need to 
  do a 

  mt -f /dev/zqft0 erase

  (you may well use another zftape device, the driver always allocates
  space for the volume tabel segment and the compression segment when
  doing an erase). You even must do an erase when using tapes that
  have been used by the original ftape. OF COURSE, THIS DAMAGES THE
  DATA ON THE TAPES. This is, because the original ftape used the 
  failed sector log for emualting file marks, while I use a  volume
  table to provide some QIC-80 compatability.                      
  
  NOTE 1: tapes written by old ftape can still be read, and zftape even
  emulates the eof marks correctly.
  
  NOTE 2: If you use tapes that have already been used by some QIC-80
  compatible backup program (under OS/2 or MS:-( ) you don't need to
  erase them. But if those programs didn't provide a compression 
  segment, the driver silently switches to non-compressing mode even
  when called via the compressing devices /dev/zqft?. zftape correctly
  locates the volumes listed in the volume table segment. You may use
  the MTEOM ioctl to skip to the end of the recorded data and apend 
  another volume. 

  Well, assuming you use an empty tape, just do a

  mt -f /dev/zqft0 erase

  to prepare the tape, then try 
  
  cd ..  
  tar -cvf /dev/zqft0 zftape-1.01 

  for making a sample backup. Then do a
  
  tar -df /dev/zqft0

  If all is well, tar shouldn't complain at all.
  You may test the non-compressing devices etc. in a similar
  manner.

6) Mail any comment, complaint, bug report to

  Heine@axpmgr.physik.rwth-aachen.de  
  or
  claus@willi.math.rwth-aachen.de
  
  Please feal free to make any comments on the (sparse?) documentation
  I wrote. I know that it needs to get improved. Software without or
  with bad description is like a computer without monitor.

  If you should succeed and use a tape-drive that supports tapes
  with more than 120MB, then please mail me even if the driver
  functions perfectly. I only have a standard 120MB drive and 
  no opportunity to test the driver for other hardware than my own.

  
 


