ADSM-L

[no subject]

1995-03-08 22:48:02
From: "Jacquelyn B. Reith" <jreith AT VNET.IBM DOT COM>
Date: Wed, 8 Mar 1995 19:48:02 PST
Subject:Re: Paul Zarnowski's comments

Paul,

I'll try to respond to your questions.  Please see the sections
with the ===>


Thanks for the response.  I agree with your thinking that the first
priority should be to find and fix the problem.  I am always somewhat
uncomfortable using OCO (object code only) products, and since I cannot
look at the compression code myself to see what the problem might be,
I was hoping that you could provide us with a description of what the
problem was.  As you say, the first priority should be to fix the problem,
but it would be nice to get a description of it at some point.  Thanks.

===> It is an error in ADSM's buffering scheme which happens in
     the rare occurrence when the final size of the compressed
     data is a multiple of 32K, plus 1 to 12 bytes.  The final 1
     to 12 bytes are being truncated.  Final compressed data size
     outside this range are not affected.



I am also concerned about the following scenario:
Let's say a user backs their system up, and some files are truncated during
the backup, due to this compression problem.  Secondly, let's say that the
user restored the bad backup to their system, for whatever reason.

Q1: Would the restore of the truncated file fail, or would it simply restore
    the file incorrectly?

===> The file would restore incorrectly.

If the file is restored incorrectly, and the user does not become aware of
the bad file, it is likely that this bad file will now be backed up again
by ADSM during the next incremental backup.  Some days later, the remaining
inactive backups of this file will expire.  These remaining inactive backups
would be the only valid copies of this file at this point, and they will
be expired.

Q2: Will this second backup be considered a "good backup" or a "bad backup"
    by the analysis tool that you are going to provide to us to determine if
    we have been affected by the compression problem?

===> This second backup will be considered a "bad backup" by the
     tool.  Howwver if the file has changed between the two
     backups it be ok unless it again happens to land in the
     problem size range.

If the second backup is considered a "good backup" by the analysis tool,
then it seems to me that there will be no way to detect whether this problem
occurred or not, on any node which restored any files.

Q3: Is this analysis correct?

===> Yes.

Q4: One last question:  In your announcement, you said that the fixes would
    be available on Friday, but I did not see an estimated date for the
    analysis tool.  Do you have an estimate?

===> The current target date is April, 1995.


I hope this helps to clarify the situation for you.

Regards,
Jacquie Reith
ADSM Technical Support
<Prev in Thread] Current Thread [Next in Thread>
  • [no subject], Jacquelyn B. Reith <=