> Suggestion for future ADSM release:
>
> Provide the ability for a "checkpoint" on a full restore.
> Last night, we started a full restore for an 8GB drive with 30 to
> 40 thousand files. After approx. 10,000 files restored, we had
> a communications failure on the server (MVS) - did not reconnect
> automatically. On the restart, we told ADSM to skip files that
> already existed - all 10,000 of them - this took time that could
> have been better spent restoring files. My suggestion is to
> optionally tell ADSM to take a checkpoint every x number of
> files (2,000 for example)... ADSM would generate a unique
> checkpoint ID that would be kept in sync on the server and the
> client. Then, in a situation similar to mine, I would look up the
I'm not sure if I fully understand the scenario here but I think your
requirement might be precluded due to the dynamics that exist inside
of the server itself. A few factors that MIGHT be in play here are:
1. Expirations take place which could change the restore dataset.
2. Active and inactive files create problems (suppose a filesystem
emptied, a backup was run and all files went inactive...) where
when restoring inactive files the restore dataset might change
or vary based upon factors that change during the interval between
comm failure and restart.
3. Variability of restore methodologies (by tree, by subdir path, etc.)
can cause problems with checkpointing, however this could probably
be overcome by providing an explicit checkpoint choice for re-restore.
I hope I've understood this requirement and not muddied the water too much.
> lasted checkpoint ID and continue the restore from there - this
> would eliminate the overhead of checking for files that were
> just restored. After the full restore is completed, the checkpoint
> files on the server and client could be deleted. While this
> doesn't seem too critical now, it will become so as the size
> of the drives increases.
Based upon my own experiences, the 8GB you mentioned is really not a factor.
It's your 40K+ files that cause the slowdown. ADSM does a very good job
of moving data.
> Bill Coughlin
> GPU Service Corp.
> wcoughlin AT gpu DOT com
>
___________________________________________________________________
Mitch Sako Phone: (415) 508-6761
Cellnet Data Systems FAX: (415) 508-6700
125 Shoreway Road Pager: (408) 989-3365
San Carlos, CA 94070 email: mitch AT cellnet DOT com
personal: msako AT netcom DOT com
|
