On Feb 12, 2007, at 9:22 PM, Anker Lerret wrote:
Since I posted yesterday, I've learned that the new copy of the HSM filesystem will not be placed on a new TSM client, but on a client that's already defined to the TSM server. That means that the RENAME NODE technique won't work. In fact, I can't see a way to tell TSM that a filespace is moving to another TSM client. It doesn't matter, though, with the RESTOREMIGSTATE technique.
Anker - The restoral of stubs is viable only when there is an HSM filespace on the TSM server to which they point. Whereas you cannot use the technique of reassigning node data, you will not have such a backing store, so the "RESToremigstate Yes" approach cannot work. You will likely have to resort to "RESToremigstate No" to fully restore the foreign file system contents to the new server, and let that migrate to the HSM backstore of the new HSM client. This can obviously be painful, and is best performed in stages, as in a directory at a time, to give migration the opportunity to operate. Richard Sims http://people.bu.edu/rbs/
