ADSM-L

Re: Restore problem with big filesystem

2005-02-02 09:33:51
Subject: Re: Restore problem with big filesystem
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 2 Feb 2005 09:33:14 -0500
Hi, Rainer -

Unfortunately, implicit restorals (where you do not explicitly name
objects to be restored) has become a difficult challenge in the
product, and remains a muddled area which sorely needs to finally be
straightened out by Development, as the product should figure out the
best approach: the mess should not be left to the befuddled,
exasperated customer.

In some cases, suppression of the more modern No Query Restore, by
explicit suppression or involvement of qualifying restoral options, can
improve restoral time, as Classic/Standard protocols are in play and a
files list is promptly sent to the client and it can make its choice.
This is what prompted you to add DISABLENQR to your option file. More
often, you want No Query Restore to be in effect, though, such that the
server generates the list of files to send to the client. However, the
client's memory and processing power may be overwhelmed by the volume
of files information (not to mention the time to send it over the
network). With NQR in effect, customers get concerned as they see
nothing coming back from the server for some time and wonder what's
going on.

Whereas you suppressed NQR, you are seeing the client examining the
inventory list, and the client is probably slowing as its virtual
storage is taxed and paging increases. In your wholesale restoral, NQR
may be the better choice, as the server may have better resources to
generate the list. Then again, it may take as long.

I wish there were a better answer: none of us wants to have to deal
with such quandries.

   Richard Sims

<Prev in Thread] Current Thread [Next in Thread>