Neil,
A common problem with any hierarchial filesystem is the number of files
in a single directory. More than (256-1024, pick your number) really
slows any access down.
ADSM has to send the client the entire subdirectory structure before it
can present the pick list.
Neither of these, however, explain your wait. I'd investigate the ADSM
server and the network for bottlenecks.
Steffan
Neal Adams wrote:
>
> I need some help regarding an NT client problem we're having and I don't have
> much experience with the NT client or NT.
>
> We have an NT client with a RAID disk setup that we run an incremental backup
> on. Currently it's occupancy looks like this:
>
> adsm> q occ rainmaker
>
> Node Name Type Filespace Storage Number of
> Space
> Name Pool Name Files
> Occupied
>
> (MB)
> ------------------------ ---- ----------- ----------- ---------
> ----------
> BIGDAWG Bkup RAID1 BKP.DLT7000 952,533
> 27,168.39
> BIGDAWG Bkup RAID1 CPY.DLT7000 952,533
> 27,168.39
> BIGDAWG Bkup Backup OS BKP.DLT7000 137
> 1.02
> BIGDAWG Bkup Backup OS CPY.DLT7000 137
> 1.02
>
> Recently the folks that administer this machine had to restore some inactive
> files using the NT client (v3). It took forever just to get a list of files
> to restore. My observation using the dsmc restore -pick for one
> file was that it took 1hr 45 min to present a list to pick from. The ADSM
> server
> was relatively quiet at the time I was doing this. They've had to wait hours
> for responses from the GUI. The command line interface appears to work a bit
> better.
>
> Is our problem because of the way the filespace backup is setup for RAID1?
> Does restore look at every file (952K worth in this case)? Why is it so slow?
> Is there something we can do to our server or client configurations to
> optimize restores? With Unix you can setup a virtualmountpoint which helps
> when backing up and restoring large file systems. Is there a similar way to
> setup an NT client?
>
> Our server is an RS6000/F40 (1 cpu) running v2 with a db that looks like this:
>
> adsm> q db
>
> Available Assigned Maximum Maximum Page Total Used %Util Max.
> Space Capacity Extension Reduction Size Usable Pages %Util
> (MB) (MB) (MB) (MB) (bytes) Pages
> --------- -------- --------- --------- ------- --------- --------- ----- -----
> 6,120 6,120 0 2,584 4,096 1,566,720 789,066 50.4 56.0
>
> We are aware our server needs more horsepower and we're in the midst of
> setting up an F50 with 4CPUs and much more memory.
>
> Thanks for any information you can give..
>
> ========================================
> Neal V. Adams
> SLAC Computing Services -- Systems Group
> phone: 650-926-2821
> fax: 650-926-3329
> email: neal AT slac.stanford DOT edu
> ========================================
|