I haven't used it myself, but it works the same way as OTG DiskExtender did. It was mentioned during discussion at our local TSM user group; at least 2 sites were using DiskExtender and LIKED the way it handled stub files.
Yes, your backup has only the stub. But the file itself, is still in the HSM storage pool (and you should have a copy pool version also, etc.) The people who liked this arrangement pointed out that if they had to do a mass restore of a hard drive, it doesn't take very long, because they only restore the STUBS, not all the MB of all the data. Then when someone wants the file, and they touch it, TSM HSM kicks in to restrieve it as usual. Just another point of view. Wanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Wednesday, January 18, 2006 9:17 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Windows HSM experiences? >> On Tue, 17 Jan 2006 13:28:36 -0500, Richard Rhodes <[EMAIL PROTECTED]> said: > We are a Novell shop that has made a decision to migrate to Windows > for file and print serving. There is talk about implementing the > HSM client for Windows to help "solve" disk space problems. > Is anyone using Windows HSM client and what are your experiences > with it - good and bad. I had a bad experience with it; it was the presentation about it in Oxford. The Windows HSM implementation is very very different from the unix one. One example: If you have a HSM filesystem, and you put a file down: 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. (!) Yes, your actual backup is now inactive. I asked about this three times. HSM might not migrate the file immediately, of course. But whenever it does, you'll cut a new copy of the (from your perspective 'unchanged') file, and make the complete version inactive. If you later retrieve the (in your opinion unchanged) file, the next incr will make another new version, and for a while your active version will be the full file. The long and short of it was that the presenter felt the Windows HSM client was appropriate for very, very static filespaces; perhaps PDF output repositories or report holding bins? But it seemed clear to me that it was not suitable for the kinds of tasks I've been accustomed to deploying on UNIX HSM. - Allen S. Rout - Apologies for the double 'very very'.