Have you ever done AUDIT VOLUME X only to have the server request that
you CHECKIN LIBV library Y? And later check in volume X? The reason
for that is that, yes Virginia, ADSM files will span tapes.
Now, then, why is Thomas Denier having the failures? I don't know.
I am inclined to wonder if his storage pool has filled up, either because
there are no scratch tapes available when the current tape fills, or
because the MAXSCR parameter is not properly set for that storage pool.
Hope this helps,
Rich
At 11:19 AM 3/12/99 -0700, you wrote:
>I would think that if a tape fills with a file, then that entire file will
>require retransmission and storage on the new tape. I don't think ADSM
>will span files on multiple tapes? But, as I write this, I begin to wonder
>about my wondering.
>
>Retries get counted in aggregate bytes transferred.
>
>Kelly J. Lipp
>Storage Solutions Specialists, Inc.
>www.storsol.com
>lipp AT storsol DOT com
>(719)531-5926
>
>-----Original Message-----
>From: Thomas Denier
>Sent: Friday, March 12, 1999 10:14 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Spurious backup failures
>
>We are running an ADSM 3.1.2.0 server under MVS. Client backups are sent
>directly to tape. Each time a tape volume fills up, the ADSM client output
>reports that the backup of the file in progress is unsuccessful, and that
>the
>backup is being retried. When the file is big enough for the client to show
>a
>percent completion indication, the percentage goes back to zero at the
>beginning of the retry and then increments at about the same rate as it did
>before the retry. We recently took a close look at statistics and volume
>contents for a specific backup. The statistics showed 5.7 gigabytes of data
>backed up and 6.7 gigabytes of data transferred over the network. Each file
>in
>progress when a tape filled up was split between the volume that filled up
>and
>the next volume mounted. The aggregate size of the split files was about
>two
>gigabytes. I don't know of a practical way to determine the aggregate size
>of
>the first segments of the files, but I would expect this to be about half
>of
>the the aggregate size of the files. These statistics and the client output
>suggest that the following sequence of events occurs when a tape fills up:
>
>1.The client sends data until the tape fills
>2.The client detects a failure in the backup
>3.The server mounts a new tape
>4.The client restarts transmission at the beginning of the file
>5.The server discards the incoming data that duplicates data already
>written
>to tape
>6.The remaining data is written to the new tape
>
>Can anyone confirm or refute this suspicion? If this suspicion is correct,
>is
>there any way to eliminate the unnecessary retransmission of data?
>
>
Richard C. Dempsey email: dempsey AT kodak DOT com
Public Online Services pager: 716-975-3539
11th Floor, Bldg 83, RL phone: 716-477-3457
Eastman Kodak Company
Rochester, NY 14650-2203
|
