Re: bad performance restoring very small nt-directories
2000-03-29 08:45:54
Subject: |
Re: bad performance restoring very small nt-directories |
From: |
Richard Sims <rbs AT BU DOT EDU> |
Date: |
Wed, 29 Mar 2000 08:45:54 -0500 |
> there is a nt-directory with only one file.
> If I restore only the file it takes 1 min.
> If I select the directory including the file it takes > 15 min
Andreas - Restoral performance with directories is an issue with multiple
platforms, as recent postings show. Serious problems like this
often have APAR entries, due to customer reports, and in searching on
"adsm restore performance" I came upon one important 1999/07 APAR, which whose
body I'm including rather than a reference, as it's content is of interest to
all of us. Note that it was closed as a Suggestion, so any resolution will be
a long time coming. Consider also that resolution will itself involve
additional client processing time and memory utilization.
APAR NUMBER: IC24321 RESOLVED AS: SUGGESTED CHANGE
ABSTRACT:
IC24321: ADSM V3 CLIENTS ALWAYS RESTORE OR RETRIEVE DIRECTORIES EVEN WHEN
PARMS SUCH AS REPLACE=NO OR -IFNEWER ARE USED
ORIGINATING DETAILS:
During ADSM restore and/or retrieve processing the objects
being restored/retrieved are being returned from the server to
the client in "restore order". This concept of "restore order"
is that the objects are returned in the order on which they
appear on the given media. This avoids restore/retrieve
performance issues of sequential volume "thrashing" (positioning
back and forth on a sequential volume) and multiple mounts of
the same sequential media. The "restore order" considers where
objects exists on sequential media and brings them back in this
order so that the media can be moved from beginning to end.
One of the side effects of this type of processing involves the
restore/retrieve of directories. When a file needs to be
restored/retrieved into a directory that does not exist yet
(because its restore order is down further) the ADSM client must
build a skeleton directory to place this file under. When the
client then encounters the directory in the restore order it
will overwrite this skeleton it originally put down. At this
time the ADSM client is not designed to track which directories
it lays down as skeletons and which were already this. This
means that the client restore/retrieves directories whenever
it encounters them within the restore order. This is true
regardless of replace=no being specified. Or regardless of
-ifnewer being used and the directory being restored being
older. The ADSM client needs a design change in this area to
track which directories it puts down as skeletons and which it
does not. It needs to only restore those where it put down the
skeleton.
LOCAL FIX AS REPORTED BY ORIGINATOR:
Restore/retrieve files to a temp location and copy them over.
RESPONDER SUMMARY:
RESPONDER CONCLUSION:
TEMPORARY FIX:
COMMENTS:
The requirement to not replace existing directories when
-REPLACE=NO is in effect involves a design change in ADSM
restore/retrieve processing that is beyond the scope of a PTF
fix. However, ADSM Development agrees with the need for this
requirement, and has accepted it for implementation in a
future version of the product.
Richard Sims, BU
|
|
|