ADSM-L

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
<Prev in Thread] Current Thread [Next in Thread>