>> On Wed, 18 Jan 2006 16:55:25 +0100, TSM <tsm AT PROFI-AG DOT DE> said:

> let us view tsm:
> you will only have two sorts of files on the filesystem: the original file
> or (after hsm migration) the stub
> (or not, it depends on the hsm configuration)

> so tsm will have the stub and the original file in its storage, how many of
> them depends on the copygroup parameters.
> often the active version will be the stub file

> hsm:
> hsm migrates the file and the file is in the tsm storage, stub file is
> left.

> so you have to mention both hsm and tsm parameters very carefuly, that no
> data is lost.

We agree.  Contrast this with the UNIX HSM implementation, in a
similar scenario to that which I discussed.  Here's the windows HSM
scenario:


]] Day 1: You run an incr, and back up the file.
]] Day 1.1: HSM decides to migrate your file.  A stub is left.
]] Day 2: You run an incr, and back up the stub. (!)

On AIX, it would go:

Day 1: you run an incr, back up the file.
Day 1.1: HSM decides to migrate your file, a stub is left.
Day 2: You run an incr, and to a filesystem client the file is
       completely unchanged.  No new copy needed, no new copy sent.

The active version is the correct version, and there's never a stub
backed up.  I think that the AIX behavior is much more clear, much
more TSM-ish.


One response to this would be using your HSM workflow to serve the
needs usually addressed by backups.  But the windows-HSM storage is
managed on the TSM server as archives, not as space-managed storage.
This means that (unless you want your HSM filesystem to just lose
files after N days) you have to set retention to NOLIMIT.

This, in turn, means that you want to be -extremely- careful about how
dynamic the space is, because you'll be keeping every version of every
file, forever.  Like I said in my initial reply: very very static
spaces.


- Allen S. Rout