This is an experimental HSM daemon and migrate tool. It is meant to be
a platform for testing ideas in HSM migration.

Written by Andrew Tridgell, August 2008

Download
--------

To download the latest version of this code use git like this:

  git clone http://samba.org/~tridge/hacksm/.git

To update it later use "git pull"


Installation
------------

To use it first setup a shared filesystem with NFS to hold the HSM
"store", putting it in the HSM_STORE location from hacksm.h (the
default is /hacksm_store). This needs to be mounted on all nodes. You
can also use GPFS for this store, as long as the filesystem you use
doesn't have DMAPI enabled. 

Then start the HSM daemon like this:

   hacksmd &

Optional parameters to hacksmd are:

        -c                 cleanup lost tokens
        -N                 use a non-blocking event wait
        -d level           choose debug level
        -F                 fork to handle each event
        -R delay           set a random delay on recall up to 'delay' seconds

The -F and -R options can be used to simulate the delays associated
with tape based HSM systems. The -N option is useful to work around a
GPFS bug that makes hacksmd unkillable when waiting for events.

The -c option is a debugging option to cleanup any lost tokens. Lost
tokens are also automatically restarted when the daemon starts up.

If GPFS has not started when hacksmd is started then it will wait for
the DMAPI service to become active. This means you can start hacksmd
at any time in the boot process.


Migration
---------

Once started, you can migrate files using the hacksm_migrate
tool. Just pass it the names of the files you want to migrate.

To view the migration status of some files you can use hacksm_ls.

TSM Installs
------------

Note that if you have TSM installed you need to disable it before
using hacksm. The simplest method is:

   onnode -p all mv /opt/tivoli /opt/tivoli.DISABLED

then reboot. 


The file store
--------------

The "store" for hacksm is just a directory with files named by device
and inode number. When a file is migrated the data is moved to the
store and a dmapi hole is punched in the original file. This mimicks
the behaviour of real HSM daemons. When the hacksmd daemon gets a data
event (indicating that someone wants to read or write the data in the
file) then the data is restored from the "store" and the file can then
be read normally.