Project gvirstor -- RC4
(c) 2006-2007. Ivan Voras <ivoras@freebsd.org>
Sponsored by Google (Summer of Code 2006)
Mentor: Pawel Jakub Davidek <pjd@freebsd.org>

----
Changelog:

rc4:
    * Fixed a bug resulting in data corruption on big (1 TB+)
      virstor devices.
    * Ported to FreeBSD 7 - this version won't work on
      FreeBSD 6.

beta5:
    * Implement IO delay when there's no physical space left on
      the virstor device.

beta4:
    * Fidgeting with ENOSPC

beta3:
    * Additions to gvirstor.8
    * Removed hack from destroy_geom (not fixed; thus you'll have
      to call kldunload twice to unload the module)

beta2: 
    * Fixed "stop" command
    * Made xml output (used by "gvirstor list") more user-friendly
    * Allowed "add" and "remove" to use full path (/dev/xxx) for
      provider names.
----

If you're using this from developer tarball edition, just run "make" 
and "make so" - these will create .ko and .so modules, and some symlinks 
to system utilities. For the gvirstor command line utility to work
You'll need to make a symlink to geom_virstor.so in your /lib/geom 
directory. After this you can use "kldload ./geom_virstor.ko" to load the 
kernel module, and "./gvirstor" command to run the userland utility.
You might want to create a symlink in your kernel directory
(/boot/kernel/ to the geom_virstor.ko you just created, so that
standard utilities can work on it)

If your kernel doesn't have INVARIANTS and WITNESS, you'll need to
edit Makefile and remove the CFLAGS line that uses them.

For example, run:
    ./gvirstor label -v -s 30000 mystor ad1s1a /dev/ad1s1b

That will create /dev/virstor/mystor with virtual size of
30 GB, using providers /dev/ad1s1a and /dev/ad1s1b.

Defaults are:
    Virtual size: 2 TB (-s 2097152)
    Chunk size: 4 MB (-m 4096)

Note that -s accepts number representing megabytes and -m
accepts kilobytes.

To add a backing storage device to the virstor device, run:
    ./gvirstor add mystor ad2s1a

With 4 MB chunks, a TB of virtual storage translates to
allocation table of 2 MB, residing in kernel. This is important
on low-end machines where, for example, kernel on a
128 MB machine will panic with a 16TB virtual device (32 MB table).

File system metadata takes a lot of chunks because it's scattered
throughout the device. With 4 MB chunks, it takes around 1 GB of 
physical storage to create UFS1 file system of virtual size 25 GB. 
UFS2 has lazy allocation so it requires less space.

With 4 MB chunks, a 1 TB virtual device requires around 2 MB of
kernel memory to support the allocation table.
