FW: Restore process dying because of lon

If this is occuring on a Novell server with an ADSM rel. 1.x client, try
upgrading to ADSM rel. 2.1.x clients.  The rel. 1.x client draws from a
smaller memory pull in building the file list.  The rel. 2.x client draws
from cache buffers.  Cache buffers might also be too small a pool; calculate
that the server will send about 27 bytes per directory entry prior to
beginning data flow.  You want >30% free cache buffers w/ all volumes
mounted, NLMs loaded, and the entire restore list completed from the server.

In other words, you can back up a server w/ volumes that are too big to
restore if there isn't enough memory on the Novell client.

Steve Kuhn     Network Mgr.   AEGIS Insurance Services
Jersey City, NJ     kuhns%aegis AT mcimail DOT com

 ----------
From: ADSM: Dist Stor Manager
To: ADSM L
Cc: KUHNS
Subject: Restore process dying because of long di
Date: Thursday, March 13, 1997 8:03AM


MCI Mail date/time: Thu Mar 13, 1997  8:06 am  EST
  Source date/time: Thu, 13 Mar 1997 14:00:12 +0100
 -------------------

Hi,

When trying to do a (test) restore of a large user file system
the restore process ended abnormally when trying to create the
needed directory structure. The error occured when a directory
with a _very_ long path name had to be created.

I would have expected that adsm would fail only in this (sub)task
and would continue to create the next directories needed for the
restore process. But in the contrary, the _whole_ restore process
died!!!
That's a great pity, because the dying occured after 1:20 h
(large user file system means 250.000 files in 4.5 GB filespace!),
and we had to restart the restore process after deleting the original
(malformed) directory structure and doing a selective backup of the
parent directory. Now we wait for the next crash ;-(.

Why does ADSM die? Should this not have been fixed as soon as possible?
Otherwise every student could prevent us from doing correct
backup/restore by simple using/typing a short shell script which
creates a directory in a directory in a directory.... you know what i mean!

Hope to hear from anybody soon ;-)

Bye,
/dh

 --
Detlev Hilberg
                                    hilberg AT rz.uni-frankfurt DOT de
Hochschulrechenzentrum der Johann Wolfgang Goethe-Universitaet
 Frankfurt/Main
Office phone: +49 69 798-28005,  fax: -28313,  priv. cellular: +49 171
4702196