The Ftape Installation Guide - File System Interface
After some correspondence with Guido Muesch I got persuaded to implement
support for transparent on-the-fly compression for ftape. Currently the
lzrw3-algorithm by Ross Williams (dated 30.06.1991) is used. Its
compression efficiency is comparable with the Un*x compress
program and it seems to be sufficiently fast.
It should be quite easy to adopt another compression-algorithm. Note however that the official QIC compression algorithm is not in the public domain. The original QIC compression algorithm is copyrighted, so we can't use it. Thus the driver is no able to read compressed data that was produced by commercial floppy-tape programs.
The compression strategy of zftape consists of compressing the data one block at a time. This is one of the reasons why every read and write access to the drive must be a multiple of a fixed block size (fixed, but tunable, see MTSETBLK).
The error recovery facilities (i.e. skipping defective data on tape and
continuing extraction behind the defect sections) when using compression
are only slightly worse than when using the driver without compression.
It might be that incidentally a tape gets partially damaged, but then
one can use the seek commands of the MTIOCTOP
ioctl
(see MTFSR, see MTBSR, see MTSEEK) to skip the defective
blocks and continue reading from the tape.
Using for example `tar -zcf ...
' for compression is much less safe
as tar compresses the entire archive, i.e. it makes the entire data
stream to be one large compressed file. Thus an error near the start of
a large backup set make the entire backup unreadable.
In contrast to this zftape (using either the device `/dev/zqft*
' or
the device `/dev/nzqft*
', see /dev/zqft, see MTCOMPRESSION)
lets you extract all portions of the archive that are still intact.
TODO: implement compression for variable block size? This should be possible, but less secure.
Use these buttons to jump to the top menu