Hi,
It does the sending on each retries. To avoid it, it would have to first
copy the file in a reserved space, check if the file changed, and send it
only it has asserted itself it is OK to be sent. This could be a
worthwhile feature in *SM if it were not for the fact that you'd need to
have a free space reserve equivalent to the size of any of the file bundles
that are sent at each transmission bursts. *SM were just not designed this
way.
You may want to exclude the files changing during the backup process, and
schedule a task to backup those files separately at a time when you know
they are not going to change.
Serge Gaudet, CMI
Consultant.
Zoltan
Forray/AC/VCU To: [EMAIL PROTECTED]
<zforray@VCU. cc:
EDU> Subject: Bytes Transferred Statistics
from AIX nodes
Sent by:
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
RIST.EDU>
25/10/2000
11:05 AM
Please
respond to
"ADSM: Dist
Stor Manager"
Once a week (or so), I go through the ADSM (MVS 3.1.2.50) server activity
log file, and strip out the "AN?4961I Bytes Transferred" messages to get an
idea of how much data is being transferred/backed up.
Recently, we noticed that a new node (AIX) was transferring more data than
the total of it's file systems (32GB on a 21GB system).
We turned on VERBOSE logging on the node to see what the !@#$%^&* was going
on.
The only thing we could come up with was the issue of RETRIES on busy
files. The log would show
"....transfering....changed....retrying.......transfering.....changed....retrying.....".
When we added up the RETRIES bytes plus the total of the filesystem, it now
adds up.
So, why is the "total bytes transfered" including RETRIES ? Does it
actually send the data, then go back and check to see if the file it just
transfered changed since it sent the data (kinda doubt it <g>) and keep
retry/sending until it runs out of retries and then gives up ?
Or is this a client bug ? This is V3.7.2.0 !
