> OK, I'll take a stab at this: You are pretty plainly asking for more
> files to be restored than you realize. Specifying a simple subdirectory
> to be restored, from even a filespace containing a vast number of files,
> is fast. e.g. RESTORE /var/mail/johndoe/* Our end-users do it all the
> time with the Unix linemode client dsmc command interface, and they're
> not phoning me to complain that it performs badly. Every time you run an
> ordinary incremental backup for this client node, a similar process
> happens so that the TSM client program can figure out which files need
> to be backed up this time. The "diff" is done on the client system after
> downloading the full list of that node's files from the server to the
> client. If that were as slow as you report, normal backups could never
> happen. So something else has to be wrong, such as asking to restore a
> lot more files than you really wanted, so that the list it is building
> of the files you want restored is growing wildly.
>
> Perhaps this is a typo in a wildcard specification. Perhaps you need to
> specify a fully-qualified path here but you are only specifying a
> relative path. Try specifying the -pick option on the restore command,
> and see how many files it comes up with for you to pick from. Try
> copying the exact specification you are using on the dsmc restore
> command, into a unix ls command, and see how many files it lists. You
> might be surprised with a lot of files - that you didn't want.

The restore finally requested a tape mount a little over two hours
after starting. It requested a second tape mount shortly after that.
It moved 8.5 megabytes of data from the two tapes to the client within
fifteen minutes. It then sat for hours with no further mount requests
and no evidence of further data transfer to the client. I finally had
to cancel the restore to enable the normal backup of the client to run.

The server administrator still has no idea how many files were included
in the restore request, but was able to tell me that the user in question
had 26 megabytes of mail. If the average size of this user's files is
the same as the overall average for the file system, there would be about
2000 files to be restored.

Running an ls command is not an option; the restore is needed because
the mail directory is question is gone entirely.

I had the system administrator send me a copy of the restore command,
which he claims to have cut and pasted from his terminal session:

dsmc restore -subdir=yes -pitdate=02/24/2003 -pittime=09:00:00
-preservepath=nobase /var/spool/imap/user/saa001 /home/erecio

The client documentation indicates that the last two operands should
have terminal slashes. Is there any chance that omitting the
slashes would cause disastrous performance problems? The system
administrator reports that the files that did get restored look
like a subset of the expected files.