It has been our experience that what degrades our performance in the large
filesystem/many small files situation has been *SM database lookups.  Of
course, we have been reclaiming tapes when they hit the 50% mark.

Now that circumstances (hours in the day) have forced us to reclaim tapes at
the 10% mark, perhaps we will begin to see problems due to fragmented tapes.

As a solution, I would suggest using the virtual mount option to slice up
large file systems into more reasonably-sized partitions and develop a
priority mechanism to determine which should be restored first.  In a file
system containing several million files, surely some must be more important
than others...

Jim

> ----------
> From:         Mark Bryant[SMTP:mark.bryant AT ZURICH DOT COM]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Thursday, September 21, 2000 7:19 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Slow restore for large NT client
>
> My view on the slow restore problem is that it is down to the tape
> technology. I've done quite a bit of testing with restores on AIX, NetWare
> and NT and can say the following:
>
> 1. I can rule out the network and server performance as the bottle neck.
> Doing a full backup and restore will give comparable performance and ADSM
> will run as fast as the network will allow. Also as fast as any other
> product (Arcserve, BackupExec).
> 2. Large filesystems containing large files will give a reasonable restore
> performance. Large filesystems with lots of small files give a terrible
> restore performance.
>
> What I think is happening is this:
> Due to the incremental forever backup method the files are becoming
> fragmented on the tapes. A file changes so a new version is written to the
> tape. The oldest version is then deleted  leaving a gap on the tape. The
> problem with fragmented tapes is that the seek speed of the tape drives is
> very slow. Some are better than others, I've found Magstar  3570's are
> quite a bit faster than DLT's. So when we come to do a full restore the
> tape drives are spending most of the time searching rather than
> transferring data.
> Arcserve and the like do not have this problem as they are generally setup
> for a weekly full, daily differential so are able to stream data off the
> tapes in one big block and are only really limited by the transfer rate of
> the tape drive.
> The probem with ADSM has really got worse over the last few years due to
> the amazing growth in disk capacity/price. It is now becoming a real
> problem when we have these big fileservers going in.
> I'm not sure what the answer is. Some things that can help are to make
> sure
> you are collocation on your tape pools and run regular reclamation to
> reduce the fragmentation.
>