> If TSM can clean up after a shutdown
> while the copy is in process, it can
> bloody well clean up after a force
> termination of the process.
I am fully with you, Tom.
But saing this, I would like to express not only my criticism of this
wanted/missing functionality, but thanks as well
to developers and product managers who invested
years of work to make this product so robust
that it " can clean up after a shutdown" - or after a crash.
>From this point of view this is probably the best backup product on the
market.
As for "kill immediately", opening an official enhacement request could
help.
regards
Juraj
-----Ursprüngliche Nachricht-----
Von: Kauffman, Tom [mailto:KauffmanT AT NIBCO DOT COM]
Gesendet: Donnerstag, 13. März 2003 21:04
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: Canceling a Reclamation FAST
Well -- yes and no.
I want to know why I can't do a 'cancel process n force=yes' (or
'immediate') and get the process to stop NOW, not after 10 hours of trying
to write a 1 GB file to a bad tape. If TSM can clean up after a shutdown
while the copy is in process, it can bloody well clean up after a force
termination of the process.
I have done the 'halt' on the TSM server before to get around not being able
to kill a process immediately. I'll do it again, if the circumstances
require it, unless I get a cleaner way of killing a process NOW and not at
some indefinite period in the future.
Tom Kauffman
NIBCO, Inc
-----Original Message-----
From: Stapleton, Mark [mailto:stapleto AT BERBEE DOT COM]
Sent: Thursday, March 13, 2003 2:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Canceling a Reclamation FAST
>Steve Harris wrote:
>>updating the drive mid transaction to online=no does it for me.
From: Paul Ripke [mailto:stixpjr AT BIGPOND.NET DOT AU]
>Sneaky! Since TSM *has* to be able to cope with this scenario
>gracefully, it does surprise me somewhat that there isn't a
>"cleaner" way of doing this - something like "cancel process
>123 immediate=y".
As I've said before, there's a good reason why many processes can't stop
on a dime.
Example:
You're running space reclamation. The server is finished copying a 1GB
file from one tape volume to another. The pointer in the TSM database to
the old copy gets updated, but you *stop* the process before the pointer
for the new copy gets written. Oops.
There's a reason for rollback, and for finishing a process. Sometimes
you've got wait; that's the price you pay for db integrity.
--
Mark Stapleton (mark.stapleton AT berbee DOT com)
|
