Double version 0.2 INTERNALS		25 Feb 1994
----------------------------

The DouBle device driver acts as an interface between the physical
(compressed) data on a device or a regular file, and a pseudo
"DouBle" block device, where non compressed data is written/read.

DouBle was originally inspired from the loop driver, written and copyright
by Theodore Ts'o.

This is how it works:

<file system> <-> <double device> <-> <double driver> <-> <regular device>
              (3)                 (2)                 (1)

<regular device> is either a real block device (such as a
disk partition) or a regular file on an existing file system.
Data on this device (or file) is compressed and should not be accessed
directly. Before it can be used, this device also need to be formatted.
<double device> is a virtual block device, where non compressed data can be
written/read. The major number for DouBle devices is currently 19.

<file system> is either a filesystem, or any utility that works with block
devices (You could do a tar on a double device). 
Finally the <double driver> does all the work.


Of course, one needs to do a few things to set up links (1),(2),(3).
1 - The regular file needs to be "formatted" - I'll explain that further
down.
2 - There is a utility (dbmount or mount) to establish links (1) and (2):
dbmount <regular device> <double device>
mount -t dble <regular device> <double device>
3 - There is a utility to break the links: (dbumount or umount). 

Following that, any request going to <double device> will be (de)compressed
and piped to/from the <regular file> transparently.

How does the driver do compression ?
On the side of link (1) it work with blocks (say 512 bytes).
on the side of link (2), it works with clusters (usually 16 blocks long).
The driver compresses each cluster and use as few blocks as necessary to
hold either the compressed cluster or the non compressed cluster (in case of
overrun). For that purpose, there are several table in a compressed device
(hence the formating step): 

The physical file/device contains a header (a), a bitmap (b) and a
block allocation table (c) referred to as BAT in the source. Regular
files used as devices also contain a block map table (d).

(a) The header contains a Magic number and relevant informations on
the size and number of physical blocks (called isize and iblocks) and
virtual block clusters (osize and oblocks).

(b) The bitmap tells which iblocks are already allocated.

(c) The BAT contains information on the type of compression, and on
which iblocks the clusters are made of. Each oblock (cluster) is made of
several (smaller) iblocks (from 1 to osize/isize), depending on the
compression factor for the cluster. 

(d) The block map table is used by the driver to access a real block
from the block number of a regular file.

Finally, there is a utility (dbcheck) to check the integrity of data in these
structures.
